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1. Introduction 


1.1 Background 

Information Technology (IT) has great potential for both enhancing exploration capability and 
simultaneously reducing overall mission cost, while assisting in conveying the results of the 
science analysis to the research community and, increasingly, to the general public. 

Accordingly, NASA’s Office of Space Science (OSS) requested an assessment of the degree to 
which IT research and development (R&D) meets the needs of future OSS missions (2006 and 
beyond). This study was led by JPL, which formed a team of technologists representing three 
Centers (JPL, ARC, and GSFC) from both the IT provider and IT customer sides. 
Representatives from commercial, academic and government sectors were also invited to 
contribute information on their IT programs and provide outside perspectives. 

NASA’s recent reorganization of IT R&D assigned most of the agency’s investment to the 
Office of Aerospace Technology (OAT). During FY2001, OAT spent about $134M in low- and 
mid-TRL (Technology Readiness Level) R&D, with a further $66M being spent by OSS and 
other codes on focused IT R&D. Further shifts in the budget occurred in FY2002 to increase 
OAT’s share of the total IT R&D responsibility. 

1.2 Objectives 

The objectives of this Information Technology Assessment Study (ITAS) were to repond to the 
following areas of inquiry posed by the Associate Administrator for OSS (as described in 
Appendix 1): 

1. Perform a critical assessment of NASA ’s planned information technology R&D and its 
relevance to future OSS missions 

2. Identify products that industry and other government agencies can best supply or perform 

3. Recommend a technology infusion strategy to make available the appropriate information 
technology to our missions. 

These three objectives proved very challenging for the team to fulfill. 

1.3 Study Scope 

The ITAS team restricted its review to the OSS IT needs and the Agency investment designed to 
address these needs, although many of the technologies reviewed are also relevant to other 
Enterprises. Table 1-1 summarizes the total current Agency investment in low- and mid-TRL IT 
R&D and estimates the portion that has the goal of meeting OSS needs. For the OAT cross- 
Enterprise investment, we asked the funding programs to determine the portion of their 
investment that is intended to directly address OSS needs, using the requirements identified by 
the user community. These were used to compute the “Investment Relevant to OSS IT Needs” 
columns in the table. 
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Table 1-1. Investment for Low- and Mid-TRL 



FY 01 

FY 02 

Total 

Investment 

(SM) 

Investment Relevant 
to OSS IT Needs 
(Provider-Estimated) 
($M) 

Total 

Investment 

(SM) 

Investment Relevant 
to OSS IT Needs 
(Provider-Estimated) 
(SM) 

OAT Investment 

133.7 

38.3 

129.0 

55,2 

OSS Technology Development 
Investment 

37.7 

37.7 

9.4 

9.4 

Other (Office of Earth Science 
and Office of Space Flight) 

28.4 

13.8 

27.2 

13.1 

Total 

199.8 

89.8 

165.6 

77.7 


* TRL - Technology Readiness Levels (Maturity) 


A significant portion of the OAT investment that previously had been focused on the aeronautic 
needs of the Agency m FY2001 has been realigned in the new Computing, Information, and 
Communication Technology (CICT) program structure to address cross-Enterprise needs. This 
realignment was not accounted for in the assessment of OSS relevance because CICT planning 
was occurring in parallel with this assessment. Thus, in FY2002 a larger proportion of the OAT 
investment could be considered relevant to OSS; this proportion is expected to grow further as 
the CICT program is fully implemented over the next year. The row in the table that identifies 
the investment of other Enterprises is included since various funding lines, such as the Office of 
Earth Science High Performance Computing and Communications (HPCC) investment, have 
relevance to OSS even though the funds come from other Enterprises. 

1.4 Approach 

During the period June 2001 to October 2001, the study team achieved the following: 

• Formed a small IT Assessment team consisting of representatives from JPL, other NASA 
Centers, other government agencies, and industry. 

• Held four workshops (1-3 days each) to bring material together for face-to-face discussions. 

• Produced high-level summaries of IT needs for OSS with input from users representing: 

— Solar System Exploration (SSE) 

— Mars Exploration Program (MEP) 

— Astronomical Search for Origins (ASO) / Astrobiology 

— Sun-Earth Connection (SEC) 

— Structure and Evolution of Universe (SEU). 

• Produced high-level summaries of NASA’s IT R&D and its relevance to the IT needs 
expressed by the OSS Themes in the five following categories chosen to represent those 
areas (within the broad field of IT) most relevant to OSS (see Section 4 for each area 
description): 

— Reliable software 

— Highly-robust autonomous systems 

— Computing, communication and distributed systems 

— Virtual mission lifecycle 
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- Science data processing, access, analysis and knowledge discovery. 

• Reviewed selected industry, other government agency (OGA), and university IT R&D 
programs (comparable in scale to NASA’s) to determine the extent of overlap in providing 
relevant IT capability, and suggested approaches to leveraging such relevant work to benefit 
OSS. 

• Fostered constructive dialogs between IT providers and Theme IT users, focused on 
identifying issues that limit the effectiveness of transferring IT to flight operations, and 
highlighted examples of successful infusion. 

• Organized the gathered reference material into a 300-page report. 

• Produced a set of high-level findings and recommendations and a stand-alone Executive 
Summary. 

Given the scope and charter of the assessment, it should be recognized that this study had several 
limitations. First, it did not attempt to perform a detailed program review of all NASA IT R&D, 
and could not uniquely identify all NASA IT R&D sources relevant to OSS needs. Similarly, it 
did not attempt a comprehensive assessment of all major OGA IT R&D programs. While it 
provided a summary of the OSS Theme IT needs and the relevant IT research products 
(primarily from OAT), the study team did not have the resources to produce an integrated IT 
roadmap or to perform a gap analysis between IT products and Theme IT needs. The study also 
did not propose new NASA programs or new organizational alignment to improve investment 
strategies in developing and infusing IT for OSS needs or attempt to pose solutions to problems 
or issues raised in the assessment. All of these limitations could be addressed in follow-on work 
by an appropriately-constituted and chartered team that, among other possible goals, could 
develop and implement a process for reproducibly managing IT infusion for the missions. It is 
hoped that the material of this study would provide a good starting point for such a team. 

1.5 Participants 

The participants of the IT Assessment Study are listed on page iii above. 

1.6 Schedule 

Four workshops were held to implement the study approach. The first was held in Ventura, 
California on June 1 1-13, 2001, with the following goals: 

• To gather information from the five Theme representatives on their proposed mission sets 
and arrive at a first cut at their perceived IT challenges 

• To survey the IT research programs at NASA (principally those funded by OAT) and arrive 
at a first cut at the products in each of the IT areas. 

The workshop included breakout sessions to foster dialog between the Theme representatives 
and IT area representatives to elicit an appropriate next-level breakdown of challenges from the 
Theme side and research areas on the IT side. The assignment after the workshop was to 
produce a textual write-up of the Themes’ mission IT challenges and of the IT providers’ 
capabilities, technologies, and products. 
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The second workshop was held at Goddard Space Flight Center (GSFC) July 31 and August 1, 
with the following goals: 

• To hear from the external representatives (OGA, Industry, Academia) describing their IT 
research programs and the IT infusion processes at their institutions 

• To review the write-ups produced by the Theme representatives and the IT areas 

• To begin construction of two mappings: one between the proposed Mission set and the 
identified IT challenges (produced by the Theme representatives) and the other between the 
IT challenges and the IT products (produced by the IT area representatives) 

• To discuss how findings of this report could or should be used 

• To discuss how to capture funding information relevant to the IT programs represented. 

The assignment after the workshop was to complete the textual write-ups and draft the mapping 
matrices. Additional assignments were made to the Center IT leads to produce short descriptions 
of the current IT infusion processes (including successes and failures) at their Centers, and to 
produce overviews of the IT research programs and funding levels. The external representatives 
were asked to provide write-ups of their research processes for inclusion in the report. 

The third workshop was held at ARC on September 6, with the following goals: 

• To iterate the matrix produced by each IT area mapping IT products to OSS Theme IT 
challenges 

• To discuss findings by the study team on the IT infusion process 

• To discuss the recommendations to be made within the report. 

The fourth workshop was held at JPL on October 23, with the following goals: 

• To focus the reporting methodology on the team’s findings and recommendations 

• To outline the format and content of an Executive Summary for immediate publication. 

In addition to these workshops, the team met regularly via telecon to coordinate inputs, track 
status, and address issues. During the entire study period, a secure web site was maintained at 
JPL to collect information gathered during the workshops, meeting minutes, and to post section 
drafts for review and feedback by all participants. 
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2. Study Overview 

The IT Assessment Study was conducted in order to formulate a first response to the three 
questions listed in Section 1.2. 

Table 2-1 indicates the approximate scale of the NASA research IT investment that was 
considered by the study team. 


Table 2-L Estimated NASA IT Research Funding in FY 2001 and 2002 






FY 2001 



FY 2002 


Program* 

Funding 

Enterprise 

Intended % 

Enterprise OSS Relevance 
Focus (Provider est) 

IT 

Funding 
($ K) 

OSS- 

Relevant 

($K) 

Intended % 

OSS Relevance IT Funding 
(Provider est) ($K) 

OSS- 

Relevant 

($K) 

Thinking Systems 
(space-based) 

OAT 

Cross 

96 

8,163 

7,801 


0 

0 

Intelligent 

Systems 

OAT 

Cross 

70 

32,000 

22,526 


0 

0 

HPCC 

R,Y,S,F 

Cross 

48 

77,203 

37,370 

45 

24,900 

11,250 

SAIT 

OSS 

OSS 

100 

2,500 

2,500 


0 

0 

AISRP 

OSS 

OSS 

100 

2,500 

2,500 


0 

0 

Mars Technology 

OSS 

OSS 

100 

5,420 

5,420 

100 

6,000 

6,000 

IPN-ISD IT 

OSS 

OSS 

90 

4,533 

4,083 

89 

4,119 

3,669 

NMP (ST6.ST7) 

OSS 

OSS 

100 

460 

460 

100 

1,546 

1,546 

ISE/NGI 

OAT 

Cross 

40 

18,000 

7,200 


0 

0 

ECS 






56 

13,400 

7,500 

CICT 

IT-Base 



0 

49,000 

0 

41 

115,615 

47,681 



Total IT 

45 

199,799 

89,860 

47 

165,580 

77,646 



OAT 


133,666 

38,297 


129,015 

55,181 



OSS 


37,735 

37,735 


9,392 

9,392 



Other 


38,378 

13,828 


27,173 

13,073 


* Acronyms are listed in Appendix 5. 


2.1 Critical Assessment of NASA IT Research and Development 

In response to the first objective of the study (a critical assessment of planned information 
technology R&D activities and relevance to future OSS missions), the study team decided that 
first a high-level overview was required both of OSS mission IT needs and of IT research. The 
former was requested from users in each Theme, addressing the proposed mission set for 2006 
and beyond. The IT needs collected from the Theme users were summarized in a set of tables 
identifying high-level IT capabilities (e.g., onboard planning and execution) as enabling, highly 
enhancing, etc. for particular missions. 

In parallel with the effort to gather Theme IT needs, the study team collected a high-level 
overview of IT research at the three participating Centers (ARC, JPL, GSFC). In order to 
address the issue of relevancy of the research, the study team first identified four broad areas of 
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IT to span the field adequately for addressing the Theme IT needs. A fifth area was identified by 
the GSFC members when they joined the study team, and all five areas are described in more 
detail in Section 4. The five areas include: 

1 . Reliable software 

2. Highly-robust autonomous systems 

3. Computing, communications and distributed systems (e.g., HPCC) 

4. Virtual mission lifecycle (e.g., modeling and simulation) 

5. Science data processing, access, analysis, and knowledge discovery. 

Where possible, research products were gathered in tables (see Appendix 3) showing 
subcategories of each broad IT area. 

For comparison purposes, Figure 2-1 shows an approximate breakdown of the investment dollars 
into each of these five areas, and shows that over half of the IT R&D budget Is allocated to areas 
(e.g., aero) that are not directly relevant to OSS. However, the estimated total proportion of IT 
R&D relevant to OSS stayed almost the same (-45%) for the 2 years shown. 


Reliable Software 
Autonomous System 
Computing and Communications 
Virtual Mission Life Cycle 
Science Data Processing 
Other IT relevant to OSS 
Other IT not relevant to OSS 



SO $20 $40 $60 $80 S100 $120 

Annual Funding (SM) 


Figure 2-1. Breakdown of IT Funding (from Table 2-1) 

2.1.1 Observations on Critical Assessment 
Capture of Mission Theme IT Needs 

An example of collected Theme IT needs is shown in Figure 2-2 for the Exploration of the Solar 
System missions, showing relevant IT in Autonomy and Control. 

All Themes are clearly relying on various IT capabilities at various levels (enabling, highly 
enhancing, enhancing). In this context, “enhancing” means “results in increase in the value of a 
mission with or without changing its cost,” and “enabling” means “results in ability to perform a 
mission that was previously not possible at any cost, with mission value remaining unchanged.” 
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Theme users have different methods both of documenting these needs and of relating them to IT 
research tasks. There is wide variability on the level of detail available describing the IT needs, 
and very few quantitative metrics are available (e.g., need for specific computational power), 
particularly for missions further out in time. Of particular note is the Technology Database, 
which provides a mechanism to relate these needs (via a rating) to tasks in the NASA 
Technology Inventory. 
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Figure 2-2. Example Mapping of Theme IT Needs to Missions 
Capture of IT Research Goals and Products 

Many products (at various TRLs) are applicable at various levels to the mission needs, and many 
are listed in the Technology Inventory (accessible online). However, there is wide variability on 
the level of detail available describing the research community IT products, and it is difficult to 
understand the relationships among competing approaches or the dependencies among products. 
The NASA Technology Inventory is currently the only repository for individual task 
descriptions, and the relationships among such tasks appears only to reside in high-level IT 
program plans (e.g., CICT). 

Nearly all OSS missions identified reliable software as having high relevance to their missions 
(the reliable software area is discussed in detail in Section 4.1). Figure 2-3 highlights the 
increasing difficulty of managing software errors as the expected size of code increases. In this 
graph, the effect of several approaches to reducing errors are shown: first, “validation and 
verification” seek to directly reduce errors by detecting them early enough to fix, while “tolerate 
errors” seeks to detect and recover from them during runtime; “scaled-up software engineering” 
seeks to handle larger projects while holding the number of errors down; finally, “managing 
complexity” seeks to reduce the slope of the line. 
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Figure 2-3. Strategies to Increase Software Reliability (see Section 4.1) 

Critical Assessment of Relevance 

Despite demonstrated willingness on both sides, there is wide variability in understanding of IT 
research areas by Theme users and of Theme needs by IT researchers. Thus, for many products, 
the degree of relevance is difficult to estimate. Moreover, there is no way to capture the degree 
to which desired products depend on other products (that may not have been identified in the 
Theme needs). For example, all missions desire reliable software, but insufficient understanding 
of competing approaches to achieving such reliability can lead to low estimates of relevancy for 
particular products. This is also true across IT areas (among which no dependencies had been 
established); to follow the reliable software example, missions requiring autonomy probably 
need autonomy software to be reliable, but may not have expressed this need in adequate detail. 
There are few mechanisms for closing these gaps in understanding and process, i.e., for 
documenting negotiated agreed needs and responsive IT research tasks. Even those using the 
above-mentioned Technology Database do not have a process for iterating these rankings to 
reach agreed closure with the providers. 

The Theme users constructed a mapping between the IT categories and the OSS themes, shown 
in Figure 2-4, where yellow represents enhancing, green represents enabling, and blank 
represents an unidentified mapping. 
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Missions through 2010 


Missions beyond 2010 

ASO .SEU SEC .MEP ESS 


ASO SEU SEC MEP ESS 



Hi Enabling I I Enhancing I I Not applicable 

Figure 2-4. Mapping of Theme Needs to Five IT Categories 

An attempt was then made to map the Theme IT needs directly to the research products, but this 
effort to engage providers and consumers encountered several problems, such as: 

• Combinatorial complexity of product breakdown, particularly on the IT side 

• Insufficient resources and disagreement on the approach and importance from both sides 

• Inadequate understanding of the others’ jargon and/or technologies, particularly in 
recognizing applicability of low-TRL research to desired capabilities 

• Variable levels of detail in IT requirements from different Themes, particularly for missions 
further in the future 

• Inadequacy of tools to assist with analysis and tracking of needs and related research tasks. 


In order to address the third of these problems, the IT researchers attempted to provide a 
mapping from each area to the mission need set for discussion with the Theme users. An 
example is shown in Table 2-2 for the Computing, Communications, and Distributed Systems IT 
area, where higher numbers indicate higher relevancy to Theme needs as estimated by the Theme 
users. 
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Table 2-2. Example Mapping IT Products to Mission Theme Needs 



ASO 

SEU 

MEP 

ESS 

SEC 

Onboard hardware 






Rad-hard processors 

4 

4 

5 

5 

4 

FPGAs 

3 

5 

4 

3 

4 

Bio/Nano/Quantum 

1 

3 

3 

0 

1 

Onboard software 






Operating Systems 

? 

3 

4 

4 

3 

Frameworks 

? 

SB 

5 

4 

? 

Formation Flying 

? 

mm 

2 


5 

Ground Computing 


■ ■ 




Parallel and Dist. Systems 

1 

mm. 

1 

1 

1 

Supercomputing Tools 

1 

i 

3 

1 

1 

Processor-in-Memory 

0 

i 

3 

1 

1 

Space Communications 






Coding/compression 

3 

5 

3 

5 

3 

Space Networks 

1 

3 

3 

0 

3 

Ground Communications 






Networking 

0 

1 

1 

2 

1 

Quality of Service 

0 

1 

1 

2 

1 

Security 

0 

1 

1 

2 

1 


Technology Development and Infusion Tracking 

There is no adequate and agreed method of tracking the progress of funded tasks to achieve 
infusion, e.g., via metrics showing increasing TRL during development, and successful transition 
to mission or commercial use. It is therefore impossible to estimate metrics of quality, such as 
the return on investment or cost savings. 

Shared Development Costs 

There is no agreed template defining participation in co-funding of IT research from concept 
through development, infusion, and beyond. Past successes have commonly resulted from ad 
hoc (probably irreproducible) approaches (e.g., Pathfinder Rover). 

2.1.2 Recommendations on Critical Assessment 
Task Initiation 

A consistent method of identifying mission needs and IT research tasks should be implemented. 
The Technology Inventory is a possible starting point for this, but would need significant 
enhancement (see next item). Whatever method is implemented, its use needs to be understood 
and agreed between mission technologists and IT researchers, and then enforced uniformly 
across both groups. 













Chapter 2. Study Overview 


w 




w 


* 5 ? 

v_/ 


V 

V 




Task Tracking 

A consistent method of tracking progress of IT research tasks and dependencies among them 
should be implemented. This method would include at least the following capabilities: 

• Show measurable applicability to (evolving) mission Theme needs 

• Measure progress (e.g., advancing TRL) of products over time 

• Track dependencies among products 

• Estimate total cost of investment and track sources of funding 

• Estimate payoff (e.g., cost savings) for successful infusions. 

Technology Infusion Process 

A process should be defined which manages task initiation and tracking described above. 
Although this needs participation from both missions and IT researchers to bridge the gap 
between them, it also requires some independence from both (to maintain the critical assessment 
function). It should be responsible to upper management for reporting and review, and it should 
contain an ongoing critical-assessment process. 

2.2 Identification of IT Research Outside NASA 

In response to the second objective of the study (identification of products that industry and other 
government agencies can best supply or perform), the study team enlisted a few experienced 
developers of information technology from universities, industry, and other government agencies 
to help address this objective. In order to keep the team size manageable, only two 
representatives from each of the above sectors were invited to join the study team. The 
individuals were chosen for their technical expertise and for their organizations’ investment in IT 
R&D dollars. The dollars invested in IT R&D by these organizations range from $380M/year to 
$5B/year. (The lower number is closer to the NASA investment level for IT R&D.) This 
collaborative approach had the potential to provide the study team with widening breadth of 
expertise, alternative points of view, and synergy among different organizations. 

In the process of addressing the above objective, the team asked the industry and government 
members to contribute to the IT assessment in the following areas: 

• Provide a brief overview of your organization’s IT program (funding, products, etc.). 

• Having heard NASA OSS Theme needs, where might your organization collaborate? 

• Provide some description of the process used by your organization to infuse IT research into 
products and customers. 

• Provide some observations or comments on this NASA IT assessment process. 

Table 2-3 provides a broadly identified set of summarized findings based on the contributions 
from the non-NASA assessment team members. 
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Table 2-3. Summarized Information from Non-NASA Assessment Team Members 



-Program Overview 
-IT R&D Funding 
-Products/Services 

Potential IT 
Collaboration with 
NASA OSS 

Process Used to Infuse 
IT To 

Customers/Products 

Comments on NASA 
OSS IT Assessment 
Process 

NSF 

-Enable US to world 
leadership in computing 
-Funding S470M in 2002 
-Robotics & human 
augmentation 
-Advanced computational 
research 

-Software engineering & 
languages 

-Networking research 

-Enabling research on 
software and hardware 
systems 

-Augmenting individuals & 
transforming society 
-Pursue scientific frontiers 
of IT 

-Pursue tools for the 
conduct of science. E.g. 
NSFNET 

-Low priority at NSF 

-Little said 

DARPA 

-Promote revolutionary IT 
innovation to support US 
national security 
-Funding $383.5M in 2001 
-Architecture & Design 
-Advanced processing and 
storage 
-Networks 

-Human-computer I/F 
-Large-scale applications 

-Complex systems; Onboard 
science 

-Data representations; 
Human I/F 

-Planning & scheduling; 
Networks 

-Robotic/Autonomic 

systems 

-Knowledge engineering 

-New DoD 5000 (See 
Appendix 4). Model for S & 
T Transition is a driver 
-Need the collaboration of 
researchers, acquisition 
PM’s and military users to 
effect IT infusion 
-Emphasis on evolutionary 
versus revolutionary IT 
development 

-A fairly organized 
approach to bring 
Mission and IT folks 
together 

Oracle 

-Information management; 
database & applications 
-Funding over $ 1 B in FY 
‘01 

-Improved system operation 
-Extend DBMS technology 
-New application design 
technology 

-DB for NASA ground- 
based systems 
-Manage large scale IT 
development 

-New application design & 
partitioning models 

-Designed to be rapid in a 
commercial, for-profit 
company 

-PM is aligned with 
development 
-Continued customer 
feedback 

-Integrated system testing 
from product inception 

-Value in Mission and IT 
folks working together 
-Not enough emphasis on 
reusability of development 
platforms 

IBM 

-Infusion of new 
technologies into products 
& services 

-$5B in RD&E funding on 
2001 

-Invention & innovation 
that align with IBM 
strategies and directions 

-In Mission focused IT 
areas: 

-Partnering & integration 
-Vertical & horizontal 
integration 

-In basic IT research areas: 
-Must-do projects 
-Internal basic space science 

-End-to-end lifecycle 
partnerships 

-Handoffs, spin-offs, and 
licensing 

- Push into infrastructure = 
shared computing 

-IT is vertically integrated 
for each Mission 
-OSS may want to look at 
horizontal layering of 
commonality leading to 
shared IT infrastructure 
spanning many Missions 

CMU& 

use 

-Basic and applied IT 
research 

-No exact funding given. 
Government funds most IT 
research 

-IT may yield intellectual 
property; licensing revenue 
potential 

-Innovations lead to 
developing start-up 
companies 

-Reliability 

-Autonomy 

-Human-in-the-loop 

operations 

-Copyrighting and patents 
generate revenue 
-Peer reviewed papers 
assure quality IT research 
-Generally a low priority 
concept in Academia 

-Little said 


Each non-NASA member addressed the four requested contribution areas and provided short 
write-ups (Section 5). The following sections summarize these findings in a more concise 
format. 


2.2.1 National Science Foundation (NSF) 

The NSF’s Directorate for Computer and Information Science and Engineering has three goals: 

• To enable the United States to uphold a position of world leadership in computing, 
communications, and information science and engineering 
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• To promote understanding of the principles and uses of advanced computing, 
communications, and information systems in service to society 

• To contribute to universal, transparent, and affordable participation in an information-based 
society. 

Current funding for IT R&D is $470M per year. 

Potential areas for collaboration with NASA OSS are in enabling research on software and 
hardware systems, research on multimodal-multilingual interactions and algorithms, databases, 
tools, modeling, visualization, and applications in the sciences. Funding of these efforts would 
be by money transfers or separate funding of each agency’s activity. At a minimum, a 
memorandum of understanding describing the scope and mechanism of the arrangement would 
be needed. 

At the NSF, IT infusion to customers and products is a low priority. At the lowest order, the 
objective of IT at NSF is to pursue tools for the conduct of science. The best example of this was 
the NSFNET, related technologies, and the first public web browser that effectively transitioned 
the ARPANET into the INTERNET and the World Wide Web. 

There was little said that would be interpreted as comments on this IT assessment. It does appear 
the NSF wants to collaborate on rover development to collect data on glaciations in Antarctica. 
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Figure 2-5. NSF Computing and Information Science and Engineering Breakdown 

2.2.2 Defense and Advanced Research Projects Agency (DARPA) 

The principal objective of IT research at DARPA is to promote revolutionary technical 
innovation in IT to support the United States national security. DARPA’ s annual IT R&D 
budget was $383. 5M in FY01 . 
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The Information Technology Office at DARPA pursues the following topics: 

• Architectures and design 

• Advanced processing and storage 

• Networks 

• Human-computer interactions 

• Large scale applications. 

Potential collaboration topics with OSS are in complex software, onboard science, data 
representations, human interfaces, planning and scheduling, robotic/autonomic systems, 
networks, and knowledge engineering. 

When considering DARPA’s process used to infuse IT to customers and products, one must refer 
to the New DoD 5000 Model for Science and Technology Transition (see Appendix 4). The goal 
of this model is a significant reduction in technology cycle time and cost, while increasing the 
ability to incrementally introduce new technologies to military systems. This evolutionary 
acquisition process provides risk mitigation by allowing phased integration of technologies into 
the product. Open systems architecture or the application of common components across 
multiple systems is also addressed as an enabling practice to increase affordability and facilitate 
evolutionary development. 

There is a need for collaboration among the researchers, the acquisition program manager, and 
the military user, with an emphasis on evolutionary (versus revolutionary) IT development. 

DARPA concluded that this IT assessment process offered a fairly organized approach by 
bringing Mission and IT proponents together. 


FY’02 

S383.5M 


Larg e S c ale 
Applic ations 
16 % 


Human Computer 
In te rac tio n 
21 % 



Architectures and 
De s ign 
31 % 


Advanced 
Pro cessing and 
S to ra g e 
16 % 


Figure 2-6. DARPA Information Technology Office Breakdown 
2.2.3 Oracle 

Oracle is in the information management business. Their FY2001 revenue of $1 IB is split 
roughly equally across product licenses and service. About 75% of this comes from Server 
business and 25% from Application business. 
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They invest over $1B on R&D, with focus on: 

• Improved operation — performance, scalability, reliability, availability, usability 

• Extending DBMS technology — Internet file system, content management, web 
caching/searching 

• New application development techniques — Java, XML, mobile operation, mid-tier 
application servers 

• Other advanced features — clustered systems, analytic processing, security, directory 
management. 

Potential areas for collaboration with OSS include a database for NASA ground-based systems, 
management of large-scale system development, new application design and partitioning models, 
and participation in the High-Dependability Computing Consortium (HDCC). 

Since Oracle is a commercial corporation, the process used to infuse IT to customers and 
products is designed to be rapid. The Oracle program manager is aligned with IT development. 
They search for continued customer feedback, and they use an integrated system of testing from 
product inception. 

Oracle agreed this IT assessment process has real value in providing an opportunity for the 
Mission and IT folks to work together. They also stated that there is not enough emphasis on 
reusability of development platforms. 

2.2.4 IBM 

IBM has eight R&D laboratories worldwide supporting all other corporate divisions by infusion 
of new technologies into products and services streams, bringing about invention and innovation 
by working directly with customers who have requirements that align with IBM strategies and 
directions, and, very importantly, distinguishing IBM for the quality of its science. 

IBM invests $5B in R&D annually. 

Potential areas of IT collaboration with OSS include: 

• In mission focused areas — partners and integrators, vertical integrators, and horizontal 
integrators 

• In basic IT research areas — must-do projects and internal basic space science. 

IBMs ability to infuse IT to customers and products is legendary. The key elements are end-to- 
end lifecycle partnerships, handoff, spin-offs, licensing, and push into infrastructure, e.g., 
research moved into a shared computing infrastructure lessens the risk and allows applications to 
be more responsive to specific customer needs. 

Regarding this IT assessment process, IBM stated that OSS technology is vertically integrated 
for each mission. It also suggested that OSS may want to look for horizontal threads or layers of 
commonality leading to possible shared IT infrastructure spanning many missions. 
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2.2.5 Academia Perspective (CMU, USC) 

The role of IT R&D in academia is one of basic and applied IT research. New concepts are 
being pursued with an emphasis on reliability in broad concepts. NSF and DoD are the primary 
funding sponsors of IT research in Academia. No exact IT funding amount was presented for 
this segment identified as academia. 

IT research may yield intellectual property but more often the results are diffused into the 
technical community. Also, innovations lead researchers to develop start-up companies to 
capitalize on market opportunities. 

Potential IT collaboration topics are reliability, autonomy, and human-in-the-loop operations. 

IT infusion into customers and products takes the form of copyrighting and patents from which 
licensing revenue is gained for academia. In addition, basic IT research yields peer-reviewed 
papers. This assures quality IT research as a base for future IT development. 

The representatives from academia offered few comments on this assessment of IT for OSS. 

2.2.6 Intra-Government IT Collaboration 

The team identified the following active NASA and NSF collaboration: 

• A Mobile Sensor Web for Polar Ice Sheet Measurements, University of Kansas. 

(NASA contact: Waleed Abdalati) 

The team also identified the following NASA and DARPA collaborations: 

• Coordination with JPL as DARPA performs the power aware computing: DARPA is 
interested in NASA challenge problems 

• DARPA’ s Synergistic Cyber Forces works with NASA Ames on human-robotic interaction 

• DARPA funded and transitioned to NASA the work on interplanetary network archtitecture 
in FY01 

• NASA Goddard and DARPA and four other DOD agencies have been co-funding ATDNet 
for several years 

• DARPA loosely coordinates with NASA NREN via the LSN working group 

• DARPA’s MARS program funds NASA’s Johnson Space Center to provide the Robonaut 
astronaut assistant with autonomous capabilities. Also, DARPA funds JPL to develop 
perception/classification/assessment of the traversability of paths in front of unmanned 
ground vehicles. 

2.2.7 Findings on Products Available/Under Development from Outside Sources 

• Many of the NASA IT needs coincide with research being done at DARPA (S383.5M/Yr) 
and NSF ($470M/Yr) 
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— NSF: high-performance computing, reliable software, modeling and simulation, sensor 
webs, autonomy 

— DARPA: sensor networks, high-speed wireless networks, low-power computing, active 
networks, bio-computing, flexible embedded computing, agent control. 

• NASA IT R&D in support of science exploration appears to have a broader use within the 
government than within industry. 

• The present NASA IT R&D intra-govemmental process is, for the most part, based on the 
dependence of individuals and an ad hoc process. A notable exception is the Space 
Technology Alliance autonomy element. 

• Technology transition requires collaboration of three diverse groups: researchers, acquisition 
program managers, and users. 

• Since there appears to be no documented and reproducible infusion process within NASA, 
little benefit to NASA is likely to be gained from creating alliances with other sources to 
perform collaborative development. The infusion process of each source would need to be 
coupled into NASA’s in ways that can be identified up-front by both sides, and this can’t be 
done currently except ad hoc. 

2.2.8 Recommendations on Use of Outside Sources 

• NASA IT R&D leaders should actively participate in the National Coordination Office for 
Information Technology Research and Development and their Interagency Working Groups. 
Presently, it appears the NASA support is good, but we believe there is room for 
improvement. 

• An intra-government alliance and partnership council for IT R&D programs should be 
pursued and may provide greater payoff for IT research dollars. The emergence of the Space 
Technology Alliance may be a good model to evaluate for IT R&D. 

• The notion of partnerships must be viewed, considered, and applied with care. Intra- 
govemment partnerships have usually worked well. With the emergence of the Space 
Technology Alliance, Air Force Space Command, National Reconnaissance Office and 
NASA partnership Council, the government has fostered numerous highly-productive 
collaborations that have minimized duplication and leveraged joint resources. 
Industry/govemment partnerships have had less success because the latter is driven by 
primarily national need considerations and the former is driven by economic market forces. 

2.3 Observations on IT Infusion Strategy 

The third objective of the study was a recommendation of a technology infusion strategy to make 

available the appropriate IT to our missions. 

2.3.1 Background 

Addressing the issue of technology infusion was clearly recognized by all of the participants as 

being of paramount importance to the future of the Agency’s missions and programs. Many of 

the participants have had direct experience with the challenges of how to infuse information 
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technology into their various projects, and thus brought a point of view to this assessment task. 
This assessment was hampered by not having the opportunity to discuss this issue with 
experienced project leaders and managers, who would have provided valuable experience and 
realism. 

While considerable discussions were held on this topic, including inputs from both Theme users 
and IT researchers and managers, team resources did not permit a systematic approach to 
investigating the many elements involved in such a process. The following then represents the 
beginnings of a much more comprehensive effort that will be required to determine the 
requirements, impediments, and necessary steps to effect a reproducible process of infusing 
information technology. 

2.3.2 Approaches to Technology Infusion 

Infusion into missions has been a severe and long-standing challenge for NASA technology 
programs. Several models for technology infusion have been identified (see Section 6.2) and are 
summarized below. 

• Over the Wall, where there is no pre-defined infusion path. Prototypes are declared mature 
by the technologists. Demonstrations and marketing occur. Users pick up only when a 
compelling (typically fortuitous) fit exists with a mission need or a user champion appears. 

• Onus on the Technologists, where they are expected to champion and fund further 
development/tailoring to accomplish the mission. This potentially compromises the 
generality achieved in the prototype and diffuses technology program activity. Only a few 
technologists are motivated for this type of activity. 

• Onus on the Technology User, where mission users conduct their own technology 
development to meet their needs. Rarely do technology products have the generality or 
potential for multi-mission use. Rarely do technology products utilize state-of-the-art 
capabilities. This approach requires a large project development budget. Most technology 
infusion into flight projects has occurred this way. 

• Shared Onus, where responsibility for achieving technology infusion is shared between the 
technology developer and the technology user. Continuing funds for technologists are 
contingent on having users signed up to accept and co-fund further development/tailoring of 
agreed-on technology product. 

• Peer-Level Coordination, where technologists and mission community users coordinate 
closely throughout the technology maturity lifecycle. Mission-experienced users inform 
technologists which capabilities are needed, with the implication that if technologists deliver 
those capabilities, those products will indeed be infused/used. Technologists inform users 
what range of solutions at state of the art are possible, and extend the possibilities for which 
capabilities can be brought within state of the practice. Coordination starts from the earliest 
roadmapping activities and continues with iterative re-evaluation and re-targeting until 
development is complete and infusion is achieved. 

To date, technology infusion has been most successful when the mission or project with the 
identified technology need possessed sufficient internal resources to develop, certify, and retire 
associated risks. That model is generally not available today because projects and programs 
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have limited resources. Under that model, long-term technology investment was severely 
limited; technology development instead was driven by immediate mission needs. Other models 
for technology infusion that have been explored in the current programmatic environment have 
generally suffered from disconnects between the mission pull side and the technology push side. 
Successes have been limited to those cases where a dedicated user champion has appeared on the 
mission side or a determined technologist carried a technology to full maturity and flight 
certification. These approaches can work but are highly uncertain. 

The current programmatic environment will likely continue to necessitate that mission and 
technology resources be managed separately. However, close coordination of goals, planning 
and management between mission programs and technology programs, along with well-defined 
and jointly agreed-on technology evaluation, maturation, and certification processes to achieve 
infusion will be needed. 

2.3.3 Impediments to Technology Infusion 

Impediments to the successful infusion of new technologies into NASA mission systems fall into 
three main categories: (1) technology provider shortcomings, (2) technology user shortcomings, 
and (3) technology infusion management shortcomings. This categorization is useful because it 
helps to focus the strategies needed to eliminate the impediments on the three major players in 
the technology infusion process. A brief discussion is presented here, with more details in the 
main body of the report. 

Technology Provider Shortcomings 

Technology providers are technologists and R&D teams who identify, assess, evaluate, and 
prototype new and emerging technologies which may satisfy current or future needs of NASA 
technology users. Principal impediments to the technology infusion process include the 
following: 

• A lack of understanding of mission needs, which results from large gaps of understanding by 
technology producers and inadequate customer focus by the technology providers. 

• A lack of effective communication with technology users, which results from an inadequate 
ability by the technologists to communicate in terms meaningful to mission development 
teams and target end-users. 

• Poor selection of infusion targets, resulting from inadequate or naive consideration of 
realistic targets and infusion opportunities by technology providers. 

• Inadequate understanding of the actual operating environment of the project, including 
unrealistic or incomplete understanding of requirements, new technology risks and benefits, 
and the inevitable constraints on schedule and resources 

• Overconfidence in the degree of technology readiness, i.e. inadequate maturity or 
overconfidence of the state of readiness of the technology to be incorporated into an 
operational system, as well as inadequate testing or other means to ensure reliable software 

• Inadequate risk evaluation, i.e., the inadequate capability by technology providers to 
effectively identify and retire risks associated with the infusion of their technologies 
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• There are no supporting infrastructure or tools that track the progress of funded IT R&D 
tasks in achieving infusion or monitoring risk reduction over time, as described in the 
findings and recommendations on the critical assessment (Sections 2.1.1 and 2.1.2). The 
existing Technology Database is insufficient because it does not track relevancy or risk 
reduction over time. 

Technology User Shortcomings 

Technology users are mission formulation teams, mission development teams, principal 
investigator teams, mission and science operation teams, and mission science users. The 
principal impediments to the technology infusion process include the following: 

• Lack of understanding of technology capabilities by mission development teams and target 
end-users 

• Lack of awareness of emerging technologies by early mission formulation teams, mission 
development teams, and prospective end users 

• Inadequate understanding of a systems environment (i.e., a myopic viewpoint of the problem 
and solutions to address it) and a regressive adherence to existing operating environments, 
architectures, systems, and components. 

• Inadequate risk evaluation (i.e., unsubstantiated perception of risk by mission development 
teams and target end-users) and inaccurate perception of risk associated with new 
technologies by mission development teams and target end-users. 

Technology Infusion Management Shortcomings 

Managers responsible for technology infusion are responsible for technology infusion planning 
and budgeting; for obtaining the personnel, facilities, and evaluation resources needed for 
technology infusion efforts; and for establishing the communication channels needed for 
successful technology infusion. Principal impediments to the technology infusion process from 
this point of view include: 

• A lack of planning, at the earliest stages of a project, for the insertion of new technology 

• A lack of openness to new solutions, resulting in inadequate appreciation and funding for 
innovative application of existing technologies-intemally or externally developed-to meet 
existing technology challenges or to enhance current capabilities/systems 

• Inadequate resources and flight opportunities for validating and maturing technologies in 
realistic environments 

• Inadequate communication and interaction between technology researchers/R&D teams, 
infusion and maintenance teams, and end-users 

• Inaccurate cost estimations for the technology development, infusion, and maintenance. 

These three groups of impediments currently present a formidable challenge to the opportunities 
presented by the infusion of new information technologies into future NASA missions. 
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2.3.4 Recommendations for IT Infusion Strategy 

Early in the assessment process it was clearly recognized by all participants that technology 
maturation and infusion is the responsibility of both OSS and OAT in terms of funding and in 
terms of management of the overall process. That this is frequently not the operating principal by 
which the two Enterprises managed their relevant programs was also recognized, yet it is the 
critical element in the success of the technology infusion process. 

Based on the discussions at the workshops and other meetings that were held during this 
assessment, the following recommendations were developed: 

• Senior management in both the Office of Space Science and the Office of Aerospace 
Technology should provide resources specifically for the purpose of developing and 
implementing agreed-upon processes for the infusion of information technology into OSS 
missions and programs. One of the ways to implement such a recommendation and provide 
clarity to the overall process is to create a formal agreement between OSS and OAT that 
spells out the roles and responsibilities between the organizations with respect to information 
technology and agree upon a regular process for defining requirements, assessing the 
relevance of ongoing work and infusing the research into missions. 

• Information technologists should be involved early and continuously in the process of 
planning and developing new missions to ensure that both mission specialists and technology 
developers clearly understand the benefits and constraints involved, and can therefore 
provide the best path to infusion of new technology. 

• Since testbeds and evaluation facilities are always critical to technology development and 
maturation, increased support of reusable software architecture and infrastructure is required 
to provide an environment for the demonstration, validation, and adoption of advances within 
the information technology arena. 

• NASA should provide incentives to mission managers to adopt new technology into their 
missions where the benefits are clearly demonstrable. .This can sometimes be done by having 
another program assume some of the risk inherent with the selection of new technologies. 

• Provide for regular reviews of technology infusion activities to ensure sufficient progress and 
resolve problems as early as possible. 

• Make technology infusion a rewarded career activity. 

• It will be the responsibility of the IT maturity group to enter and validate data. 

• The necessary tools and environment should be put in place to uniformly track progress of IT 
research tasks and dependencies between them. These tools should include the following 
capabilities: 

— Show measurable applicability to (evolving) Mission Theme needs 

— Measure progress (e.g., advancing TRL) of products over time 

— Track dependencies among products 

— Estimate total cost of investment and sources of funding 

— Estimate payoff (e.g., cost savings) for successful infusion. 
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2.4 Conclusion 

Figure 2-7 summarizes in a high-level form NASA’s technology development and infusion 
approach compared with industry and other government agencies. The challenge for NASA is 
linking emerging IT R&D with emerging mission needs. If it were simply a matter of linking 
emerging IT R&D with existing OSS missions (or vice versa), the coupling would be relatively 
easy. When both are emerging, it is a delicate, coevolutionary process, one that requires a highly- 
iterative coupling between the technology providers and users. This is because as IT R&D 
emerge, they affect the OSS missions, and as the OSS missions emerge, they influence the IT 
R&D. Hence, this is the challenge for NASA and other high-tech organizations. As new 
technologies and new OSS missions or markets engage in the dance of complexity, leaders must 
deal with enormous discontinuities, increasing volatility, and ever-increasing evolution of 
capabilities. The stakes are high: the broad field of information technology is critical to many 
future NASA missions. In the end it will be the tension of change in the learning process that 
will close the gap between IT R&D and engineering operations and, in the process, will lead to a 
new way of planning and implementing future NASA missions. 

Type of Technology 

NSF Research Category Basic Advanced Engineering 

research development operations 

DoD Category 6.1, 6.2 6.3 6.4 

NASA TRL 1 to 3 4 to 6 7 to 8 


Approach to Infusion/Technology Transfer 


National Science Foundation 



Defense Department 


External transfer not a part of the NSF mission 

Internal transfer to NSF science and technology 
Investigators 


DARPA 

Services 

Industry 

IBM 


Oracle 


NASA 

OAT 

OSS 



Follows the DoD 5000 Model (See Appendix 4) 



Does Nobel Prize winning science 

End-to-end lifecycle partnerships for tech development & 
infusion 

Essentially no basic research 

Customer driven; products validated in internal Beta tests 





Conducts basic research and some applied research 



Conducts limited advanced development & operates mission 


Figure 2-7. NASA Infusion Approach Compared with Industry and OGAs 
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3. IT Needs/Interests for Future OSS Missions 

The following sections (3. 1-3.5) were provided by users for each of five OSS Theme areas as 
follows: ASO, SEU, MEP, ESS, SEC. Each user was asked to overview the Theme and 
Proposed Mission Set, and then specify “IT Challenges” for these missions (from the Theme 
perspective). These Challenges were to be mapped (see Section 5) to IT Research capabilities 
and products (see Section 4). 

3.1 Astronomical Search for Origins (ASO) 

3.1.1 Theme Background 

The Astronomical Search for Origins Theme seeks to answer two broad questions: 

• How did we get here? 

• Are we alone? 

The first question relates to the formation of the first stars and galaxies, the formation and 
evolution of the chemical elements in subsequent generations of stars, and the formation and 
evolution of planetary systems around those stars. The second question involves the 
development of new observational techniques to detect the presence of planets as small as Earth 
in orbit around other stars and to search for possible biologic activity on the surfaces of those 
planets. 

ASO investigates how the chemical elements necessary for life have been built up and dispersed 
throughout the cosmos. We seek to explain how planets originated around our Sun and other 
stars — planets that might support life. We observe nearby stars for evidence of other planets; in 
the future advanced observatories in space may be able to directly image such relatively small 
objects across the vast interstellar void. Beginning with life found on Earth, we conjecture about 
what kinds of environments could bear and support life, and how common habitable planets 
might be. Is there now, or has there ever been life beyond our own Solar System? 

3.1.2 Proposed Mission Set 

The answer to the question “How did we get here?” involves tracing our cosmic roots. In this 
process we examine formation of galaxies; the formation of stars; formation of heavy elements; 
and the formation of planetary systems. 

When asked, “Are we alone?”, we search for life outside our own Solar System. We will search 
for other planetary systems; search for habitable planets; identify remotely detectable bio- 
signatures; and search for ‘smoking guns’ indicating biological activities. These missions have 
ambitious scientific goals and as a result, push the limits of technology capability. 
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Missions Supporting “How Did We Get Here?” 

The universe we see today is rich in structure. Clusters and super-clusters of galaxies are 
interspersed with vast, virtually empty voids, and the galaxies can appear totally isolated or in 
the process of merging with local companions. Yet observations to date of the very early 
universe show it to have been very smooth and almost featureless. How did the later structure, 
the basic extragalactic building blocks of the universe, come to be? What laws of physics 
worked to fill the gap between the primitive universe and the complexity we observe in the 
present? 

Hubble Space Telescope (HST) 

Discoveries by HST have invigorated astronomy in many areas. HST’s new instruments are 
expected to continue the observatory’s spectacular accomplishments. These upgrades include 
the installation of the Advanced Camera for Surveys, a new cooling system to reactivate the Near 
Infrared Camera and Multi Object Spectrometer, the Cosmic Origins Spectrograph and the Wide 
Field Camera-3. 

Space Infrared Telescope Facility (SIRTF) 

The next major space observatory will be the SIRTF, the final element in NASA’s family of 
“Great Observatories.” SIRTF consists of a cryogenic telescope and science instruments for 
infrared imaging and spectroscopy. Once in operation, SIRTF will contribute extensively to the 
understanding of star and planet formation, and will investigate the formation and early evolution 
of luminous galaxies. SIRTF will have unsurpassed sensitivity throughout the infrared 
wavelength regime. 

Next Generation Space Telescope (NGST) 

Expected advances in detectors, lightweight optics and cryogenics will allow a mission that can 
extend the spatial resolution achievable with HST to wavelengths in the near and mid infrared. 
This will allow direct observation and study of the earliest stars and galaxies. NGST will be the 
first large space telescope to have a deployed primary mirror. The mirror will be larger in 
diameter than the rocket that is used to launch it and it must unfold and align itself automatically 
in orbit. 

Stratospheric Observatory for Infrared Astronomy (SOFIA) 

While SIRTF will have unsurpassed sensitivity throughout the infrared wavelength regime, the 
SOFIA will complement the space mission with much better spatial and spectral resolution for 
the detailed study of bright objects. A key scientific goal of SOFIA will be the investigations of 
conditions within the interstellar medium that enable the formation of stars and planets. As an 
aircraft, rather than a space observatory, SOFIA has several unique characteristics. It can 
continually upgrade its instrumentation and serve as a critical training ground for new 
generations of instrument builders. 
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Far Ultraviolet Spectroscopic Explorer (FUSE) 

FUSE provides very high-resolution ultraviolet spectra of the interstellar medium, giving 
information on the chemical content of material between stars and galaxies. Far ultraviolet light 
in the Universe can help us understand more about conditions right after the Big Bang, the 
dispersion of chemical elements in galaxies, and the composition of interstellar gas clouds from 
which stars and planets form. A complement to other Origins missions, the focus of FUSE on the 
far ultraviolet permits astronomers to study the many important atoms, ions, and molecules that 
cannot be investigated otherwise. 

Missions Supporting “Are We Alone?” 

Keck Interferometer 

The Keck Interferometer, a ground-based facility, will combine the light collected by the world’s 
two largest optical telescopes, the twin 10-meter Keck telescopes on Mauna Kea in Hawaii, to 
undertake a variety of astrophysical investigations. By combining the light paths from each twin, 
astronomers will gain the capability of a single telescope the size of the distance between them. 
That's about the equivalent of an 85-meter mirror — almost the size of a football field. With the 
addition of four proposed 1.8-meter "outrigger" telescopes that are located nearby. Origins 
astronomers eventually hope to have the ability to simulate a telescope with mirrors anywhere 
between 25 and 140 meters. 

Space Interferometry Mission (SIM) 

SIM will serve important objectives in both technology and science. For technology, it will 
demonstrate precision metrology and aperture synthesis imaging, both vital for future optical 
space missions. Its science contributions stem from its anticipated tiny positional error circle for 
observed objects, only 4 micro-arcs; this is about 100 times better than the Hipparcos astrometry 
mission. This precision will make SIM a powerful tool for studying the distances, dynamics, and 
evolution of star clusters in our galaxy, helping us to understand how stars and our galaxy were 
formed and will evolve. It will extend our census of nearby planetary systems into the range of 
small, rocky planets for the first time. SIM will also improve the calibration of luminosities of 
standard stellar distance indicators to enable us to more accurately measure distances in the 
universe. 

Terrestrial Planet Finder (TPF) 

TPF will extend the search for signatures of life beyond our Solar System. TPF will be an 
interferometric telescope array that will separate the infrared light of a planet from that of the star 
that it orbits in order to measure the spectrum of the planet. It will be able to search about 200 
nearby stars for planets and identify any that possess warm atmospheres containing significant 
amounts of water or oxygen. This would indicate the possible presence of biological activity of 
some kind. To do so, the design for TPF will build upon large aperture cryogenic optics and 
infrared detector technologies also needed for the NGST, the beam control and nulling 
capabilities of the ground-based Keck Interferometer and SIM, and the precision free-flying 
demonstration of the STARLIGHT mission. 
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STARLIGHT 

The STARLIGHT mission will test new technologies by flying two spacecraft in formation and 
using laser beams to keep the spacecraft aligned in precise po sit ions relative to each other. Our 
first space-based interferometer, STARLIGHT will test and demonstrate formation-flying 
technologies for the first time. Working at similar distances with a combined telescope and 
interferometer system, TPF will be able to provide the first direct detection of planets around 
other stars by taking family portraits of distant solar systems that may resemble our own. Planets 
will appear as single points of light. 

3.1.3 Summary of the ASO Technology Component 

Technologies and Capabilities Expected from the Planned Missions and Technology 
Programs 

• Precision formation flight 

• Space-based optical interferometry 

• Large lightweight deployable space optics 

• Large format UV, VIS, IR, sub-mm detector arrays 

• Deep optical nulling (starlight suppression) 

• Full aperture wavefront sensing and control 

• Integrated optical system modeling 

• Lightweight precision space structures 

• Large optical system integration and test 

• Effective ground testbed design and utilization 

• Flight technology demonstrations 

• Large optical system architectures 

• Sparse aperture image analysis. 

Likely Characteristics of Far-Term Optical Systems 

• 20-40- ? meter apertures - cryogenic temperatures 

• Visual to infrared wavelengths - diffraction limited 

• Kilometric-scale formation flight collector arrays 

• Large “as deployed” optical surface errors 

• Time-dependent wavefront and alignment errors 

• Full-time, active, multi-layer wavefront control 

• Ultra-lightweight materials and structures 

• Very large thermal management structures 

• Deep space trajectories and operations. 
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3.1.4 Summary of ASO Information Technology Needs 

All Missions Will Be Computationally Intense 

• Flight System Challenges 

— All of the usual space flight requirements 

— Examples of additional unique control requirements 

° Active structural metrology and optical wavefront error sensing 
o Active hyper-precision control of optical surfaces, metering structures, and optical 
path lengths 

° Precision Formation Flight 

• Design Simulation Challenges 

— Integrated System Modeling 

— End-to-end optical performance analysis in the presence of all disturbance and 
deformation sources 

• I&T Performance Validation Challenges 

— Reliable simulation of zero-g performance based on 1-g tests 

— Reliable simulation of impossible system level testing 

Role of Information Technology in the ASO Future 

• ASO technology planners do not foresee NASA IT investments as an enabling requirement 

— Phenomenal rate of privately supported IT development is more than adequate 

— Expectation that unique ASO needs must be internally supported 

— Limited understanding of NASA IT investment goals 

• Opportunity of substantial mission and theme enhancement through appropriate IT focus 

— Reduced flight software cost 

— Enhanced software reliability 

— Accelerated IT hardware qualification for flight 

— Support of specialized IT capabilities for simulation and testing of large precision 
structures and large space optical systems. 




The ASO mission IT capability needs are shown in Table 3-1. 


V-/ 


w 


33 



Chapter 3. IT Needs/Interests for Future OSS Missions 


Table 3-1. ASO Missions versus IT Capability Needs 


Mission 

Mission Capability Needs 

Autonomy 

High 

Performance 

Computing 

Highly Reliable 
Software 

Simulation and 
Modeling 

Missions Support 

ing “How did we get here?” 

Hubble Space 
Telescope 



Enhancing 


Space Infrared 

Telescope 

Facility 



Enhancing 

Enhancing 

Next Generation 
Space Telescope 


Enhancing 

Highly 

Enhancing 

Enabling 

Stratospheric 
Observatory for 
Infrared 
Astronomy 


Enhancing 

Enhancing 


Far Ultraviolet 

Spectroscopic 

Explorer 





Missions Support 

ing “Are we alone?” 

Keck 

Interferometer 





Space 

Interferometry 

Mission 



Highly 

Enhancing 


Terrestrial Planet 
Finder 

Enhancing 

Enhancing 

Highly 

Enhancing 


STARLIGHT 



Enhancing 

Enhancing 


Note: Blank entries are equivalent to “Not Applicable” usually because the mission is 
operational or past a point in its development where significant new technology infusion is 
practical. 
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3.2 The Structure and Evolution of the Universe (SEU) 

3.2.1 Theme Background 

The SEU Theme envisions a series of space science missions that will take us to the limits of 
space and time. These missions, collectively known as Cosmic Journeys, seek to understand the 
nature of gravity - the force generating the fantastic outpouring of energy around a black hole 
and which may have been intertwined with the other three fundamental forces at the moment of 
the Big Bang. The goal of our Cosmic Journeys is to solve the mystery of gravity. 

The Structure and Evolution of the Universe seeks to answer the following broad questions: 

• What powered the Big Bang? 

• What is the Universe made of? 

• What is the nature of space and time? 

A direct image of gravity at its extreme will be of fundamental importance to Physics. Yet 
imaging a black hole requires a million times improvement over Chandra. Over the next 20 
years, the SEU Theme missions will take us closer and closer to a black hole though the power 
of resolution. Each successive mission will further us in our step-by-step journey with 10- or 
100-fold increases in resolution as we approach our goal of zooming in a million times closer. 
Each step will bring us new understandings of the nature of matter and energy. 

The study of gravity at its extremes requires a systematic use of spectroscopy and imaging of the 
highest and lowest energies and direct measurements of gravity waves. The need to either have 
very large baselines in a single spacecraft or multiple spacecraft functioning as an extended 
instrument with a very large baseline drive many of the needs in the SEU theme. 

3.2.2 Proposed Mission Set 

GLAST 

GLAST is a gamma-ray observatory mission that will observe jets of particles that shoot away in 
opposite regions from a supermassive black hole at near the speed of light. GLAST, up to 50 
times more sensitive than previous gamma-ray observatories, will unlock the mechanism of how 
the enigmatic jets form. 

The GLAST mission will comprise two instruments: the Large Area Telescope and the GLAST 
Burst Monitor. GLAST’ s specifications are the following: a huge FOV (> 20% of sky); energy 
response is broadband (4 decades in energy, including unexplored region > 10 GeV; 
unprecedented PSF(point spread function) for gamma rays (factor > 3 better than EGRET); no 
expendables means a long mission without degradation; large area (factor > 7 better than 
EGRET). All this results in factor > 30 improvement in sensitivity over EGRET. 
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Constellation-X 

The Constellation-X mission will probe the inner disk of matter swirling into a black hole, using 
spectroscopy to journey 1,000 times closer to a black hole than any other mission before it. With 
such resolution, Constellation-X will be able to measure two key properties: the mass and spin of 
black holes. This X-ray mission will also map the distortions of space-time predicted by Einstein. 
Constellation-X draws its superior resolution by pooling the resources of four X-ray satellites 
orbiting in unison into one massive X-ray telescope. 

ACCESS 

ACCESS is a cosmic ray detector that will be launched and attached to the International Space 
Station in about 2007 to help us understand the origin, variety, distribution and life span of 
elementary particles in our galaxy. The origin of the highest energy cosmic rays observed in 
nature is not understood. They are almost certainly extragalactic. 

OWL 

OWL will attempt to determine the origin and characteristics of the highest energy cosmic rays. 

A pair of instruments will observe the air fluorescence trail produced by a highly energetic 
cosmic ray. Precise triggering electronics will be required to capture the fluorescence trails. 

ARISE 

The ARISE mission will produce radio-wave images from the base of supermassive black hole 
jets with a resolution 100,000 times sharper than Hubble. Such unprecedented resolution can 
reveal how black holes are fed and how jets are created. ARISE will attain this resolution 
through interferometry. This technique is used today with land-based radio telescopes. Smaller 
radio telescopes spread out on land — perhaps one mile apart — can work together to generate a 
single, huge radio telescope with the collecting power of a 1-mile radio dish. ARISE will utilize 
one large radio telescope in space with many other radio telescopes on Earth, bringing what is 
now a land-based technology to new heights. 

SPECS 

The primary goal of SPECS is to provide a definitive observational basis for understanding the 
history of and the processes that drive the development of complex stmctures from the 
homogeneous early universe. To obtain a detailed view of the optically-obscured star-forming 
systems in the early universe; we need the ability to measure the luminosities, redshifts, metal 
abundances and morphologies of galaxies back to the epoch of their formation. SPECS achieves 
this goal with sensitive submillimeter interferometry and spectroscopy. There is also little 
practical experience with image reconstruction from far IR detectors and spectral-spatial 
interferometers like SPECS. Test and verification of analysis algorithms remain to be done. 
SPECS provides high sensitivity and HST-like angular resolution in the far infrared, a wide field 
of view, and spectral resolution about 10 4 . Since submillimeter radiation from the early universe 
is faint, cryogenic telescopes with background-limited direct detectors are required. The angular 
scales of the relevant stmctures are very small, so interferometric baselines ranging up to around 
1 km are required. 
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MAXIM 

We will travel closer and closer through resolution. The MAXIM mission, a million times more 
powerful than Chandra, will capture a direct image of a black hole. MAXIM will be another 
interferometry mission, with many smaller components positioned in a deep Earth orbit to focus 
X-ray photons onto a detector. X-ray interferometry, an emerging technology, has the potential 
to resolve the event horizon of a supermassive black hole in the nucleus of a nearby galaxy and 
at the center of our galaxy. This is equivalent to resolving a feature the size of a dinner plate on 
the surface of the Sun. With MAXIM, we will be able to see light and matter plunging across the 
event horizon. We will also see up close how gravity distorts light and how time comes to a 
virtual standstill at the event horizon. 

LISA 

There is another window to the Universe, different from light waves, through which we can see 
the deepest, most dust-enshrouded sources of strong gravity. LISA is a mission that will probe 
the Universe through the detection of gravitational waves. These waves come from the violent 
motions of massive objects, such as black holes. Gravitational waves can pierce through regions 
of space that light cannot shine through, for matter does not absorb these waves. As such, LISA 
can detect black hole activity buried within the dust and gas that other types of telescopes cannot 
see. With gravitational waves unimpeded by even the foggiest patches of the Universe, LISA 
will detect far more binary black holes than any satellite that will come before it. These are 
supermassive massive black holes in colliding galaxies or massive stellar black holes orbiting 
each other. As the orbits slowly break down, the black holes move closer and closer to each 
other, creating larger and larger gravitational waves as they spiral together. Finally, the black 
holes coalesce in a tremendous outpouring of energy. Like a ship floating on the ocean, LISA 
will detect the subtle waves that “rock” its gravitational antennae — moving them less than 100 
times the width of an atom over a distance of 5 million kilometers. LISA comprises three 
satellites orbiting the Sun in the form of a triangle connected by laser beams. The beams will 
measure the change in distance between satellites caused by a gravitational wave. LISA will 
specifically detect low-frequency gravitational waves and will thus complement ground-based 
gravitational wave detectors now being built, which detect higher-frequency waves. The lower- 
frequency waves would be those waves produced by coalescing massive black holes, as opposed 
to merging neutron stars, white dwarfs, and smaller black holes. LISA and spacecraft for the 
measurement of gravity waves require the SEU Theme needs enabling technology IT advances 
in techniques for constellation flying where the separation between spacecraft must be known to 
picometers with baselines of millions of kilometers. 

ACCESS on International Space Station 

ACCESS, a galactic cosmic ray detector, will help us understand the origin, composition, 
distribution and life span of elementary particles in our galaxy. Cosmic rays are among the few 
samples of matter we have from outside our Solar System, for comets and large meteorites that 
bombard the Earth all originate from within our Solar System. Cosmic rays, therefore, carry 
great histories. ACCESS' goal of detecting galactic cosmic rays will help piece together where 
they came from and contribute to our understanding of the structure of the Universe. 
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We know from previous research on the origin of the elements that heavier elements are created 
as a star depletes its nuclear fuel of the lighter elements, hydrogen and helium. Lighter elements 
fuse into heavier ones. When a star explodes, these heavier elements fly into space, often 
creating even heavier elements, such as uranium. The elements are accelerated to nearly the 
speed of light by a mechanism not well understood. ACCESS will collect and analyze these 
elements that were produced, perhaps, by exploding stars millions of years ago. 

Three instruments make up this mission: an element identifier, a relativistic identifier, and an 
energy identifier. No major technology developments are required. Technology is essentially 
off the shelf. Some development will be needed in scaling silicon solid-state detectors to a large 
area, and in wide-dynamic-range application specific integrated circuits. 

Gen-X 

Gen-X will image 1000 times deeper than Chandra, observing sources with Lx 1040 erg s' 1 at 
z = 5. It will also be able to obtain high resolution spectra from sources 100-1000 times fainter 
than those observable by Constellation-X. The scientific goals will be to probe the X-ray 
emission from the universe at z = 5-10. It would thus observe the formation of the first quasars, 
the creation of the first metals in starburst galaxies, and the formation of galaxy halos. The 
development of this mission will require a technology investment over the next decade. 

3.2.3 SEU Mission and Technology IT Needs 

The SEU mission IT capability needs are shown in Table 3-2 and the SEU technology IT 
capability needs are shown in Table 3-3. 


Table 3-2. SEU Mission IT Capability Needs 


Mission 

Mission Capability Needs 

Autonomy 

High 

Performance 

Computing 

Highly Reliable 
Software 

Simulation and 
Modeling 

GLAST 

Enhancing 

Enhancing 

Highly 

Enhancing 

Enhancing 

Con-X 

Enhancing 

Enhancing 

Highly 

Enhancing 

Enhancing 

OWL 

Enabling 

Enabling 

Highly 

Enhancing 

Enabling 

ARISE 

Enabling 

Highly 

Enhancing 


Enabling 

SPECS 

Enabling 

Enabling 

Highly 

Enhancing 


MAXIM 

Enabling 

Highly 

Enhancing 

Highly 

Enhancing 


LISA 

Enabling 

Highly 

Enhancing 

F IIH 


Gen-X 

Enabling 

Enabling 



ACCESS 

Enhancing 

Enhancing 

Highly 

Enhancing 

Enhancing 
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Table 3-3. SEU Technology IT Capability Needs 


Technology 

Product 

State-of-the-Art 

Performance 

Required Performance, Need Date, 
Enabling/Enhancing 

Distributed Spacecraft Thrust Area 

Formation Precision Formation 

Control Control. 

Linear and Angular 
Precision in 
Formation Control 

l 

ST-3, SIM ; EOI ground test and 
simulation- 100m; ST-3 
Simulation:1cm. 

ST-3 Simulation: 1 arc-min 

(LISA) Maintain a positional accuracy of 
<10nm/sq. root (Hz) 72008-2014/ 

ENABLING 


Precision Formation 
Control. 

EOI ground test and simulation- 
100m; ST-3 Simulation:1cm. 
ST-3 Simulation: 1 arc-min 

(Gen-X) Maintain accuracy of a few mm. 
/2008-2014/ ENABLING. 


Very High Precision 
Formation Control 

EOI ground test and simulation- 
100m; ST-3 Simulation:1cm. 
ST-3 Simulation: 1 arc-min 

(MAXIM) Micron station keeping. 
/2015+/ ENABLING. 


Precision Formation 
Control. 

EOI ground test and simulation- 
100m; ST-3 Simulation:1cm. 
ST-3 Simulation: 1 arc-min 

(Gen-X) Station keeping, robotic mirror 
assembly at L2 from modular sections. 
/201 5+/ ENABLING. 


Linear and Angular 
Precision in 
Formation Control 
with Tethers. 

EOI ground test and simulation- 
100m; ST-3 Simulation:1cm. 
ST-3 Simulation: 1 arc-min 

(SPECS) Formation Flying with Tethers, 1 
Km baseline formation flying with minimum 
5 year life and complete U,V plane 
coverage in 1 day. /2015+/ ENABLING. 

High-Rate Data Delivery 



RF Systems 

1-8 Gbps Data 
Rates 

ACTS 622 Mbps 

(ARISE) High data rate (1-8 Gbps) /2008- 
2014/ enhancing. 

Optical 

Systems 

1-8 Gbps Data Rates Optical Communications 

(ARISE) High data rate (1-8 Gbps) /2008- 
2014/ enhancing. 

Thinking Space Systems 



System Health 
Maintenance 

Pattern Recognition 

GLAST mission to detect 3 
interesting events identified out of 
100,000 triggers/day 

(OWL) Achieve on-board pattern recognition 
of evolving air-shower; rejection of 
backgrounds; determine arrival direction to 
<1 degree /2008-20 14/ ENABLING. 


Pattern Recognition 

GLAST mission to detect 3 
interesting events identified out of 
100,000 triggers/day 

(OWL) Achieve on-board pattern recognition 
of evolving air-shower; rejection of 
backgrounds; determine arrival direction to 
<1 degree /2008-20 14/ ENABLING. 

Ultra-Light Structures and Space Observatories 


Deployable 

Structures 

Robotic Assembly 

Ground Test 

(Gen-X) Robotic assembly of mirror at L2 
from modular sections delivered 
separately/201 5+/ ENABLING. 

Erectable 

Structures 

Robotic Assembly 

Ground Test 

(Gen-X) Robotic assembly of mirror at L2 
from modular sections delivered 
separately/201 5+/ ENABLING. 

Structural 

Control 

Quiet Structures: 
Vibration Isolation 

Lab demo 30 dB broadband 

(Gen-X) Segmented mirror with controllable 
segments for in-situ alignment and 
realignment to common focus. /2015+/ 

ENABLING. 

In-Situ 

Manufacturing 

Mirror Control 

Ground Test 

(Gen-X) Segmented mirror with controllable 
segments for in-situ alignment and 
realignment to common focus. /2015+/ 

ENABLING. 
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3.3 Mars Exploration Program (MEP) 

3.3.1 Introduction 

The Mars Exploration Program (MEP) is a science-driven, technology-enabled enterprise with 
the goal of characterizing and understanding Mars. Foremost among the questions addressed by 
the program is: “Did life ever arise on Mars?” MEP includes a series of ambitious missions with 
launches every 2 years leading to a sample return mission with a launch date in 2011, and 
continuing after that date with a focus on deep subsurface access. Information technology is 
already playing a key role in MEP and has potential for reducing costs and risks and enriching 
science return. 

The purpose of the IT assessment being conducted by OSS is to “assess the state of relevant 
information technology being developed or planned in NASA, other government agencies, 
universities and industry and to determine to what degree NASA’s IT R&D effort help realize 
the strategic goals of OSS.” To facilitate this objective, the MEP has: 

• Performed an assessment of how information technology is currently being used in 
developing the enabling technology for future Mars missions 

• Invited applied information technologists working on the Mars Technology Program to 
specify those advances in IT that would have most impact on the MEP and hence OSS’s 
strategic goals 

Our expectation is that this information may be useful in determining if NASA’s basic IT 
research activities are in alignment with NASA’s strategic goals. 

3.3.2 Planned Mission Set (as of Summer 2001) 

MEP was formulated by the Office of Space Science in collaboration with international partners 
and includes launches at intervals of 2 years through 2011 and beyond, alternating between 
orbiters and lander missions. Orbiters will be launched on 4-year centers in 2001, 2005, 2009, 
and will be used as telecommunication relay stations after they carry out their primary science 
missions. Landers will be launched on 4-year centers in 2003, 2007, 2011. The mission set for 
the post-2005 period includes a sample return mission. In addition, “Scout missions” for which 
the entire mission as opposed to just the payload will be competitively selected, are planned for 
launch on 4- year centers starting in 2007. Scouts may be orbiters or landers or other types of in 
situ missions — airborne vehicles, balloons, or even networks of small landers. 

Mars 2003 Lander 

The 2003 Mars Exploration Rovers (MER) mission uses the airbag lander technology applied in 
Mars Pathfinder and will deliver two rovers to separate locations on the surface of Mars. Each 
rover will have a sophisticated instrument payload and takes advantages of advances in 
autonomy and mission operations technology to travelling about 50m across the surface of Mars 
each day. 
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Mars Smart Lander 2009 (MSL’09) 

This mission will introduce innovations in landing and surface mobility. * The primary goal is to 
demonstrate the ability to make a safe landing at any locality on Mars. To achieve this goal, three 
complementary technologies are being developed. 

• Precision landing - This will reduce the uncertainty in the landing location from about 

100 km to about 4 km - making it possible to avoid hazardous craters, mountain ranges, and 
canyons 

• Hazard avoidance - An autonomous landing system will enable detection of small scale 
hazards such as boulders and small ravines and ridges during descent to the surface and 
maneuvers to avoid these hazards 

• Robust landing - In the event surface obstacles are encountered — perhaps because of failures 
of precision landing or hazard avoidance systems — the lander will still be robust enough to 
tolerate rocks up to 1 meter and slopes up to 20 degrees 

A second feature of MSL’09 is mobility. It will deploy a rover 2 to 3 times longer than the 
MER’03 rover and capable of more than 10 times the range. A radioisotope power system (RPS) 
is being considered for the rover that would enable a lifetime of at least two years. Improved 
rover autonomy is being developed to enable safe navigation as well as autonomous science 
operations. 

The time delay inherent to Earth-Mars communications makes it impractical to carry out long 
traverses with Earth supervision. Technology is also under development to reduce the number of 
uplinks and downlinks required in making scientific observations. New instrument concepts will 
be integrated with rover platforms. These technologies will be fully tested and validated with 
full-scale remote terrestrial field trials in simulated Mars terrain, including simulated science 
operations 

Mars Sample Return (MSR) 2011 

Probably the most ambitious planetary mission to date, this mission will bring samples of 
carefully selected rock and soil from the surface of Mars for analysis back on Earth in order to 
address the question of whether life ever arose on Mars. The mission as presently conceived has 
the following elements: 

• An MSR lander will deliver a rover equipped with sampling equipment and a Mars Ascent 
Vehicle (MAV) to the surface of Mars 

• A rover will place a Mars sample in the MAV and the MAV will propel the sample canister 
into Mars orbit 

• An orbiter (a joint NASA/CNES mission) will rendezvous with the sample canister, capture 
it, and return it to Earth. 


1 “Second Generation Landed Missions,” J. Graf, et al., IEEE Conference in Big Sky, Montana, Paper No. 
0-7803-6599-2/01, March 12, 2001. 

2 “An Overview of Flight Computer Technologies for Future NASA Space Exploration Missions,” by Leon Alkalai, 
Third IAA Symposium on Small Satellites for Earth Observation, April, 2001. 
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Autonomy plays a critical role in all phases of the MSR mission, in particular for safe landing, 
for rover-science operations, and for Mars orbit rendezvous. 

3.3.3 MEP Information Technology Needs 

MEP has been defined for the next decade and a Mars Technology Program (MTP) has been 
established to support MEP. Applied information technologies specific to the Mars Program 
needs are an integral part of the MTP. However, the MEP depends on the OAT information 
technology program for basic (low TRL) research in IT and relies on support of other NASA or 
DoD programs for support of mid- and high-TRL technologies that have broad applications in 
civilian and military use of space. 

Space Flight Computers 

• Many of the missions in the MEP require high performance computing. The MSL’09 requires 
high performance- power efficient processing for safe landing (hazard avoidance) and for 
surface mobility (navigation and science data analysis). The MSR’ 11 will need high speed 
processing for orbit rendezvous in addition to the above mentioned functions. Because of 
susceptibility to severe environmental conditions - vacuum, thermal cycling and most serious 
of ionizing radiation- special purpose space computers have been developed. As a 
consequence the capabilities of space flight qualified computers lagged many years behind 
what was commercially available but have recently begun to catch up: 

• Common flight computer used for the Cassini Satum mission developed in the late 1980s and 
launched in 1997 has only a 1 MIPS capability. 

• RAD 6000 mission flight computer used for the Pathfinder mission developed in the early 
1990s and launched in 1996 has a 5-22 MIPS. It is the top of the line flight qualified 
computer available today. 

• X-2000 system flight computer planned for launch in 2008 on the Europa Orbiter mission is 
based on the IBM PowerPC R 750 and is expected to execute at 200 MIPS. 

Despite the 200X performance gain since Cassini, the X-2000 computer is still a factor of 10 
behind the most state-of-the-art commercial off the shelf today and this gap will widen further by 
the time of launch. 

Recommendations: There are currently no NASA programs that are addressing flight computer 
development beyond the X-2000 computer under development for Europa Orbiter. 

Consequently, future NASA information technology programs should focus on 

• Shortening the time between a the commercial introduction of new computer technology 
development and its use in space 

• Minimizing the cost of implementing flight qualified computers through innovations on 
software fault tolerance, design, and packaging. 

Flight and Ground Software 

For missions as complex as those in the Mars Exploration Program, technology developments 
are needed that can reduce the costs and risks associated with both ground and flight software. 
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Assuming that convergence between flight and ground processors can be achieved, the following 
objectives for cutting the costs and risks of flight and ground software apply: 

• Fault protection - Make fault protection an integral part of the design and not an afterthought 

• Goal oriented behavior - Software architectures that support goal-oriented behaviour will be 
needed to accomplish objectives in autonomous surface exploration with the goal of 
approaching the capabilities of a human geologist. It is more effective to make high-level 
specifications of needs rather than at lower level 

• Migration from ground to flight - The ability to refine functions in ground systems and then 
to migrate them to the space processor enables these functions to be implemented without 
human-in-the-loop control. 

• Resource usage - Incorporate resource management as an integral part of the design not an 
afterthought. This can allow systems to be operated much closer to their margins. 

• Compatibility - Allow incorporation of legacy code in autonomy. 

The Mission Data System (MDS) under development at JPL is focusing on the development of 
these capabilities with the goal for first use in a 2007 Mars Smart Lander mission. The current 
plan is that the MDS will be used for the entry-descent-landing (EDL) functions and it may also 
provide the software framework for implementing rover autonomy in the same mission. 

Migration of software from ground to flight, and incorporation of sophisticated goal-oriented 
behavior is greatly facilitated by closing the gap between commercial and flight computers. To 
that extent, the goals in flight hardware and software are closely coupled and developments in 
hardware will enable innovative software solutions. 

Recommendations. Develop software frameworks capable of migration from ground to flight, 
and support goal-oriented behavior that incorporate integral resource allocations and fault 
protection. 

Ground and Onboard Autonomy 

Limitations on bandwidth for communicating between the Earth and Mars and the time delay - 
many tens of minutes - for signals to travel between the Earth and Mars poses major challenges 
for the operation of robotic vehicles. The bandwidth can be increased through the introduction of 
new technology. The latency is fundamental and requires innovations in both ground and 
onboard autonomy to improve the ability of vehicles to navigate and to explore Mars 3 . 

Among the onboard autonomous capabilities are: 

• Accurate position estimation in natural terrains; i.e., Where am I? This requires improved 
dead-reckoning through inertial and odometry methods as well as referencing to natural 
features. 

• Reliable internal state estimation; i.e., How am I? This requires improved health monitoring 
and fault detection. 


3 “In Situ Exploration Technology IT Needs and Capabilities,” by R. Volpe, NASA OSS Information Technology 
Assessment, Ventura, California, June 11-13, 2001. 
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• Accurate environmental characterization. This includes not only knowing where the hazards 
are but also where and what things of interest should be explored. 

• Improved control within this environment. This includes obstacle detection and avoidance 
and servoing on natural features to carry out close inspection and sampling. 

• Planning and scheduling for onboard science and data representation. 

Among the advances in ground software that can assist the ground operation team in making 
more informed and rapid decisions are: 

• Smart design to eliminate need for smart control 

• Collaborative software development environments 

• Better validation through simulation and experimentation 

• Collaborative operations environments 

• Autonomous operations on the ground 

• Mission use of techniques before migration on-board in subsequent missions. 

The MTP has been supporting the development of a number of software tools that are used in 
operating a rover on Mars. Some examples of the applied information technologies that are being 
used in implementing autonomous mobile missions are: 

• Rover modeling and simulation and site properties synthesis. This tool will be the key to 
providing the models needed to implement goal-oriented behavior in a rover. 

• Web interface for telescience that allows a distributed investigator team to operate a rover in 
an environment characterized by large control latency 

• VIZ developed at ARC which represents the current state of the art in scene visualization for 
supporting a scientific exploration mission. 

• Coupled Layer Architecture for Robotics Autonomy (CLARAty) is being used in the Mars 
Technology Program as a framework for robotics. Integrating this capability with that of 
MDS is the critical next step. 

Recommendations. In order to make the best use of future developments in IT, it is vital for 
these developments to be designed in a way that promotes early insertion into flight missions. In 
CLARAty, for example, the interfaces and standards have been established and this has proved 
to be an effective way of incorporating new software. 

Modeling and Simulation 

Given the impossibility of fully verifying total system performance in a relevant environment, 
high-fidelity modeling and simulation plays a vital role in characterizing and validating the 
performance of the complex technologies and systems needed for MEP. Improving the fidelity 
of simulation requires more powerful computers and advances in algorithms. However, as with 
flight and ground software, software reuse is a major theme and involves ensuring that the tools 
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can be used for multiple missions and throughout the lifecycle of missions 4 . This must be 
accomplished without compromising the usability of these systems. A variety of simulation tools 
are in use within the MEP - these include specialized simulators for mission phases involving 
aerodynamic entry and targeting (POST and AEP), as well as more general-purpose spacecraft 
simulators such as Darts/Dshell. The latter represents an effort in the MTP to unify a number of 
disparate simulator elements into a comprehensive multi-mission simulation tool capable of 
supporting specific mission lifecycle needs as well as reuse for successive MEP missions. 

• Multiple Mission Domain Modeling. The key issue is the ability to flexibly support multiple 
missions with extensive software reuse but without burdensome overhead. For example, the 
DARTS/DSHELL system developed at JPL incorporates several capabilities that can be 
tailored to each mission application including: 

— Spacecraft dynamics models - These incorporate flexibility and multibody elements; 

— Environment models include both real and fractal generated terrains, atmospheres, and 
gravity 

— Planetary models include ephemeris data and Spice kernels depicting the relationship of 
the space vehicles to the planet 

— Spacecraft device models include both active (e.g., Lidar) and passive (e.g., IMU) 
Sensors, and Actuators such as (e.g. thrusters, wheel motors) 5 . 

— Simulation state and parameters. 

• Lifecycle Capability. The issue is the ability to support a single mission through different 
stages of its lifecycle; POST for example, supports algorithm-in-the-loop validation of EDL 
guidance and control. Again DARTS/SHELL can support: 

— Analysis environment - Matlab/Simulink 

— Standalone 

— Mission simulation - workstation 

— Real-time testbed - VxSim/VxWorks 

— Subsystem and System testbeds 

— Hardware-in-the-loop/ATLO testbeds - bus I/F 

— Faults 

— Operations testbeds. 

• Usability. Finally, a key feature of the modeling and simulation system is the ease of use and 
the ability to effectively adapt and apply the system to multiple missions and different phases 
of the mission lifecycle. Key features important here are 

— Logging, checkpointing, and data probe; i.e., peek/poke 

— Real-time graphing, data monitoring 

— Visualization, including 3-d visualization of spacecraft actions 

— Verification utilities to allow comparison of data sets 

— Fault injection interfaces 


4 “Mars Exploration Program IT Needs and Capabilities in Spacecraft Simulation,” J. Balaram, NASA OSS 
Information Technology Assessment, Ventura, California, June 11-13, 2001. 

5 “Mission Environment Modeling and Simulation,” Meemong Lee, NASA OSS Information Technology 
Assessment, Ventura, California, June 11-13, 2001. 


w 


45 


Chapter 3. IT Needs/Interests for Future OSS Missions 


— Automated parametric exploration of simulation variable-space for Monte-Carlo and 
sensitivity analysis. 

• Applications Examples. The DARTS/DSHELL tool is being used in MEP for entry-descent- 
landing; surface navigation and mobility; and rendezvous and sample capture. 

— Entry-descent-landing capabilities include: 

° High-fidelity real-time, tether flight-train dynamics 
° Aerodynamic subroutine libraries from the POST mission/aero simulator 
« Monte-Carlo variance reduction for complex multi-body dynamical systems 
° Landing impact simulation 

° Terrain/instrument response (scanning Lidar, phased array radar, imager) 

— Surface navigation and mobility capabilities include: 
o Wheel-terrain configuration kinematics 

° Nonlinear articulated rover kinematics/dynamics 
o Vehicle stability, traction estimates 
° Resource generation and usage. 

• Verification and validation of simulations. Ability to incorporate risk in the simulation, and 
increasing the level of application of the simulations. Verification involves: 

— Comparison of simulations against Viking/Pathfinder data sets 

— Cross-comparison of simulations tools against each other; e.g., real-time Darts/Dshell 
against POST mission simulator 

— Comparison against and reproduction of experimental program data sets from Rover 
Mars Yard and EDL rocket-sled tests. 

Recommendations. In order to promote the maximum reusability of code, modeling, and 
simulation systems must be designed to support multiple missions and to support any given 
mission throughout its lifecycle. This functionality counts for little unless it can be implemented 
in a usable fashion. Validation of these tools with a series of tests in the laboratory or in Earth- or 
space-based tests is crucial to build confidence in their applications in the Mars environment. 

3.3.4 Summary of MEP Information Technology Component 

Information technology is ubiquitous in the implementation of systems for Solar System 
exploration, computer hardware and software on the ground and in space is needed to operate the 
exploration vehicles. Modeling and simulation systems are needed in all phases of the project 
lifecycle to design, build, test, and validate these complex systems for operation in alien 
environments. 

Information technology is also ubiquitous and the scale of commercial investments in IT dwarf 
those of NASA. The pace of change in this technology is phenomenal. Accordingly the NASA 
investment must often leverage commercial efforts and must be carefully directed to avoid being 
rendered obsolete by rapid developments. 
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The insertion of applied information technology into Solar System exploration is also rapid 6 . 
This is particularly the case in the Mars Exploration Program. Accordingly, it is vital that 
NASA’s basic research efforts in information technology be closely coupled to the applied side 
and that efforts are taken to ensure rapid infusion of technology. The approaches for achieving 
effective infusion need to be better understood. 

The MEP mission IT capability needs are shown in Table 3-4. 

Table 3-4. MEP Mission IT Capability Needs 






Mission 










Post 



2003 

2005 

2007 

2009 

2011 

2011 

V 




Rend 





Technology 

MER 

MRO 

Valid 

MSL 

MSR 



Space Flight Avionics 

NA 

NA 

H. Enh 

H.Enh 

Enab 

Enab 


Shorten time for flight qualification 

NA 

NA 

H. Enh 

H.Enh 

Enab 

Enab 

w 

Enable use of COTS in space 

NA 

NA 

H. Enh 

H.Enh 

Enab 

Enab 


Minimize cost of flight qualification 

NA 

NA 

H. Enh 

H.Enh 

Enab 

Enab 

w 

Flight and Ground Software 

NA 

NA 

H. Enh 

H.Enh 

Enab 

Enab 


Ground-Flight migration 

NA 

NA 

H. Enh 

H.Enh 

Enab 

Enab 

Support goal oriented behavior 

NA 

NA 

H. Enh 

H.Enh 

Enab 

Enab 


Incorporation of legacy code 

NA 

NA 

H. Enh 

H.Enh 

Enab 

Enab 


Ground and Onboard Autonomy 

NA 

NA 

H. Enh 

H.Enh 

Enab 

Enab 


Collaborative S/W development 

NA 

NA 

H. Enh 

H.Enh 

Enab 

Enab 


Collaborative ops environments 

NA 

NA 

H. Enh 

H.Enh 

Enab 

Enab 

Effective insertion into flight 

NA 

NA 

H. Enh 

H.Enh 

Enab 

Enab 


Modeling and Simulation 

NA 


H. Enh 

H.Enh 

Enab 

Enab 

w 

Multiple Mission Domain Modeling 

NA 

Enh 

H. Enh 

H.Enh 

Enab 

Enab 

w 

Lifecycle Capability 

NA 

Enh 

H. Enh 

H.Enh 

Enab 

Enab 

E~ ' : 

Usability 

NA 

Enh 

H. Enh 

H.Enh 

Enab 

Enab 


Validation 

NA 

Enh 

H. Enh 

H.Enh 

Enab 

Enab 


Most of these technologies are enabling because we cannot afford to do the mission without IT 
breakthroughs. 


6 “Communications and Networks,” Norm Lamarra, Anthony Barrett, Thomas McVittie, Larry Bergman, NASA 
OSS Information Technology Assessment, Ventura, California, June 11-13, 2001. 
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3.4 Exploration of the Solar System (ESS) Non-Mars Missions 

3.4.1 Theme Background 

The Solar System Exploration Program seeks answers to fundamental questions about the Solar 
System and life. How do planets form? Why are planets different from one another? Where did 
the makings of life come from? Did life arise elsewhere in the Solar System? What is the future 
habitability of Earth and other planets? To answer these questions, the Solar System Exploration 
Program seeks to understand the origins and evolution of the planets and other bodies of our 
solar system, including Earth; environments habitable by any form of life; life itself; and how 
Solar System processes affect the future of Earth and humanity. 

3.4.2 Proposed Mission Set 

The exploration of the solar system is driven by the desire to understand the planets and the 
environment in which they exist. The current set of strategic missions consists of the eight 
highest priority science investigations in the field of planetary exploration. These missions have 
ambitious scientific goals and as a result, push the limits of technology capability. The following 
paragraphs describe the current concept for each mission. 

Comet Nucleus Sample Return ( CNSR) 

CNSR will encounter and land on a comet, collect and store a sample of the comet nucleus 
material, and return it to Earth for study. The mission has several key technical challenges 
requiring autonomous operations: a long cruise period which requires adaptive sequencing and 
fault monitoring and recovery; complex operations near the comet and on the surface requiring 
autonomous decision-making and hazard avoidance; and science operations in a relatively 
unknown environment. Each of these elements requires the spacecraft to operate essentially 
independent of the ground controllers for some period of the operation and local decision making 
enables the mission to deal with unanticipated conditions and collect high priority science data. 

Europa Missions 

The Jovian moon Europa is one of the most scientifically interesting objects in the Solar System 
because of the strong possibility that a liquid water ocean exists underneath its ice-covered 
surface. If a subsurface ocean exists on Europa, it can be assumed to contain both organic 
molecules and heat sources from tidal effects, the decay of radioactive elements, and geophysical 
mechanisms. Europa’ s subsurface ocean environment may be similar to that of the deep ocean 
hydrothermal vents on Earth where remarkable life forms have been detected. The possibility of 
finding traces of biotic or pre-biotic materials has led to a high science interest in a Europa 
Lander mission. This mission is technologically challenging in several areas and requires 
autonomous capability to complete essential elements of the mission. Most critical are the entry, 
descent, and landing phases that must be accomplished under local control. In addition, the long 
cruise period requires onboard health maintenance and fault monitoring to ensure the successful 
completion of the mission. Prior to the Europa Lander mission, NASA plans to send an orbiter 
to assist in determining the presence of Europa subsurface water, measure ice thickness and 
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interior properties, and image surface features. This mission will add to the collection of 
scientific data gathered by the Galileo mission, which currently is conducting periodic flybys of 
the Jovian moon. Autonomy technology needs requirements for this mission are presented as an 
example in Section 5. 

Neptune Orbiter 

The Neptune orbiter mission is a continuation of the detailed exploration of the outer planets in 
the same manner as the Galileo mission to Jupiter and the Cassini mission to Saturn. The overall 
science goals of the Neptune Orbiter mission are: to study the rings, ring arcs, and shepherd 
satellites; map Triton’s surface features and examine its geologic history; examine the 
composition, structure and dynamics of Neptune’s atmosphere; and image and determine the 
densities of the satellites Larissa, Proteus, and Nereid. To accomplish these activities at the great 
distances requires autonomous health maintenance for the long cruise and orbital operations. 

Mission to Pluto 

Pluto is the only planet in the solar system that has not yet been explored. A flyby of the Pluto- 
Charon system has been formulated along with a continuing mission to one or more of the 
asteroid-sized Kuiper objects. The major objectives are to characterize surface geology and 
morphology of Pluto and Charon, map the surface composition, and characterize the neutral 
atmosphere of Pluto and its escape rate. 

Titan Organics Explorer 

The Titan Organics Explorer mission is a follow-on to the Cassini/Huygens Probe, and provides 
a detailed in-situ exploration of the Saturnian moon Titan. To meet the objectives, several 
mission concepts have been studied, including both aerobot and rover missions. Autonomous 
operations for the critical atmospheric entry and descent phase is required, as well as 
autonomous operations for the surface or atmospheric vehicle. 

Saturn Ring Observer ( SRO) 

SRO is designed to place an observing spacecraft in a unique orbit around Satum to observe the 
rings. This orbit places the spacecraft above the rings in synchronous rotation with the ring 
particles, and the spacecraft observes the interaction and dynamics of the particles. The 
overarching goal is to understand ring processes and evolution as a model for the origin of 
planetary systems. This will involve measurement of ring particle physical properties, dynamics, 
and spatial distribution. To do this, a non-Keplerian orbit has been developed which requires 
periodic orbit maintenance activities to maintain its position relative to the rings. This operation 
must be controlled locally in response to the dynamic environmental conditions. 

Venus Surface Sample Return (VSSR) 

VSSR is a very challenging mission. The principal science objective is to return samples of 
atmospheric and surface material to Earth for detailed chemical analysis. Knowledge of the 
surface chemistry of Venus is based on limited observations done by the Venera landers. 
Understanding the surface material will help in calibrating models of the evolution of the 
atmosphere and the interior. In the same manner as other sample return missions, autonomous 
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capabilities are required for atmospheric entry, descent and landing, and for surface operations. 
Venus places an additional constraint on the surface operations due to the extremely hot 
environment (-760 K at the surface). The total surface operation is limited to approximately 1.5 
hours, and must include autonomous decision-making ability to meet the science goals. 

3.4.3 Mission Information Technology Needs 

Comet Nucleus Sample Return 

• Autonomy capability needs 

— Safe landing in a low-gravity, dynamic environment 

— Intelligent in situ data collection 

— Rendezvous and docking 

— Maintenance of sample integrity during return to Earth. 

• Enabling technology requirements rationale 

— Onboard planning and execution for replanning in a dynamic environment 

— Instrument data processing for use during landing operations 

— Safe landing systems for hazard avoidance and precision landing in a poorly modeled, 
dynamic environment 

— Rendezvous and docking for rendezvous with an Earth-return vehicle. 

• Enhancing technology requirements 

— Monitoring and diagnosis to enhance fault protection in order to decrease risk. 

• Guidance, navigation, and control (GN&C) capability needs 

— Accurate, fuel-efficient, low-cost cruise 

— Accurate approach phase navigation and orbital operations near comet nucleus 

— Safe and precise landing 

— Rendezvous and docking 

— Efficient SEP trajectory design algorithms. 

• Enabling technology requirements 

— Continuous low-thrust GN&C algorithms: accurate flight path determination during 
continuous, low-level thrusting 

— Near small body GN&C algorithms: flight path estimation and control for instrument 
pointing, overflight of desired areas, and collision avoidance in the vicinity of small, 
irregular, outgassing body 

— Precise landing and hazard avoidance GN&C algorithms for safe landing to 50 meter 
accuracy. 

• Highly enhancing technology requirements 

— Continuous low-thrust trajectory design algorithms to minimize propellant usage and 
reduce launch mass 

— Rendezvous and docking GN&C algorithms for safe, accurate rendezvous and docking 
far from Earth (enabling with orbiter scenario). 
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• Enhancing technology requirements 

— Cruise, approach, and on-orbit GN&C algorithms to achieve 50-100 km orbit 
determination accuracy during cruise with minimal operations cost. 

Europa Orbiter 

• Autonomy capability needs 

— Low-cost cruise 

— Robust encounter operations due to possible 30-day lifetime in Jupiter radiation 
environment. 

• Highly enhancing technology requirements 

— System software for low-cost operations to contend with long duration cruise phase, 
highly enhancing due to reliance on ongoing developments. 

• Enhancing technology requirements 

— Onboard planning and execution: reduction in operations cost, robust sequencing, 
autonomous replanning, bonus science 

— Instrument data processing: data compression, ID interesting data for retargeting 

— Monitoring and diagnosis: cruise monitoring, data summarization, adaptive onboard data 
archive. 

• Guidance, navigation, and control capability needs 

— Low-cost cruise 

— Accurate approach and orbit phase navigation 

— Minimal delta-V to achieve capture into Europa orbit. 

• Enhancing technology requirements 

— Delta-V efficient trajectory design algorithms: minimize delta-V expenditure and time to 
achieve capture 

— General cruise, approach and on-orbit GN&C algorithms: achieve accurate navigation 
and minimize ground operations cost. 

Europa Lander 

• Autonomy capability needs 

— Safe landing system 

— Low-cost cruise 

— Data compression. 

• Enabling technology requirements 

— Instrument data processing as part of safe landing system 

— Safe landing system due to the dynamic landing environment. 

• Enhancing technology requirements 

— Monitoring and diagnosis: applicable to all cruise and encounter phases 

— System software for low cost operations: migration of operations functions during long 
cruise. 
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• Guidance, navigation, and control capability needs 

— Accurate, fuel efficient, low-cost cruise and orbiting of Jupiter 

— Accurate approach phase navigation 

— Minimal delta-V to achieve arrival at Europa 

— Safe and precise landing. 

• Enabling technology requirements 

— Precise landing/hazard avoidance GN&C algorithms: landing to 1 km accuracy in a 
nearly atmosphere-free environment. 

• Highly enhancing technology requirements 

— Delta-V efficient trajectory design algorithms: large number of orbits and satellite 
encounters in complex multibody gravitational environment. 

• Enhancing technology requirements 

— General cruise, approach, and on-orbit GN&C algorithms: accurate and low cost 
navigation during cruise, orbiting of Jupiter, and encounter operations. 

Neptune Orbiter 

• Autonomy capability needs 

— Low-cost operations for long duration cruise 

— Low-cost on-orbit operations 

— Efficient data return 

— Onboard re -targeting of interesting features. 

• Enhancing autonomy technology requirements 

— System software for low cost operations: migration of operations functions to reduce 
cruise and encounter cost 

— Monitoring and diagnosis: autonomous built-in test to reduce ground intervention and for 
fault protection 

— Instrument data processing: 10: 1 data compression, onboard data editing, change 
detection and possibly autonomous retargeting 

— Smart sensing: reduce the time required to generate routine sequences. 

• Guidance, navigation, and control capability needs 

— Efficient SEP or solar sailing trajectory design algorithms 

— Accurate, fuel efficient, low-cost cruise 

— Accurate approach phase navigation 

— Flight path estimation and control during aerocapture. 

• Enabling GN&C technology requirements 

— Continuous low thrust GN&C algorithms: accurate flight path estimation and control for 
imprecise, low-level SEP thrusting 

— Aerocapture/aeromanuevering: estimation and control of hypersonic flight path through 
an imprecisely modeled planetary atmosphere. 

• Highly enhancing GN&C technology requirements 
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— Continuous low thrust trajectory design algorithms: reduce propellant usage for SEP 
option. 

• Enhancing GN&C technology requirements 

— General cruise, approach, and on-orbit GN&C algorithms: accurate, low cost navigation 
during cruise and on approach to Neptune and Triton. 

Mission to Pluto 

No requirements are specified because no reference design exists. 

Titan Organics Explorer 

• Autonomy capability needs 

— Low cost operations for long duration cruise phase 

— Safe landing 

— Robust in situ operations 

— Opportunistic sample selection. 

• Enabling technology requirements 

— Safe landing system: landing in an unknown environment 

— Onboard planning and execution: reduction in mission risk during aerobot operations 

— Instrument data processing: landing and aerobot operations in a dynamic environment. 

• Highly enhancing technology requirements 

— Monitoring and diagnosis: fault protection during highly adaptive in situ operations 

— Smart sensing: opportunistic sample selection, controlled timing of sample selection 
based on aerobot operational constraints, autonomous resampling. 

• Enhancing technology requirements 

— System software for low cost operations: low-cost cruise operations during 6 year cruise. 

• Guidance, navigation, and control capability needs 

— Efficient SEP or solar sailing trajectory design algorithms 

— Accurate, fuel efficient, low-cost cruise 

— Accurate approach phase navigation 

— Flight path estimation and control during atmospheric flight 

— Safe and precise landing 

— Navigation of the in situ vehicle. 

• Enabling technology requirements 

— Continuous low-thrust GN&C algorithms: accurate flight path estimation during 
continuous, imprecise, low-level thrusting 

— Aerocapture/aeromaneuvering GN&C algorithms: aerocapture into bound orbit at Titan 
and for descent to surface 

— Precise landing/hazard avoidance GN&C algorithms: safe landing on Titan’s poorly 
characterized surface 

— Rovers and other low-speed vehicle GN&C algorithms: navigation of rover or aerobot. 
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• Highly enhancing technology requirements 

— Continuous low thrust trajectory design algorithms: reduce propellant usage for SEP 
option. 

• Enhancing technology requirements 

— General cruise, approach, and on-orbit GN&C algorithms: accurate, low-cost navigation 
during cruise and on approach to Titan. 

Venus Surface Sample Return 

• Autonomy capability needs 

— Safe landing 

— Robust operations in an extremely short in situ encounter 

— Rendezvous and docking. 

• Enabling technology requirements 

— Safe landing system: hazard avoidance critical in Tessera region 

— Instrument data processing for use during in situ operations 

— Rendezvous and docking for rendezvous with Earth-return vehicle. 

• Highly enhancing technology requirements 

— Monitoring and diagnosis to achieve more advanced fault protection in all encounter 
phases. 

• Enhancing technology requirements 

— Intelligent sensing: robust sampling of a rock within 90-min. time constraint. 

• Guidance, navigation, and control capability needs 

— Accurate, fuel-efficient, low cost cruise, and Earth return 

— Accurate approach phase navigation to achieve proper entry corridor 

— Accurate, reliable estimation and control of hypersonic flight path through imprecisely 
known atmosphere 

— Safe and precise landing 

— Rendezvous and docking 

— Accurate navigation for balloon ascent 

— Efficient SEP trajectory design algorithms. 

• Enabling technology requirements 

— Rendezvous and docking GN&C algorithms: safe, accurate rendezvous and docking at 
Venus 

— Aerocapture/aeromaneuvering GN&C algorithms: aerocapture then aerobrake to circular 
orbit, then descend into atmosphere 

— Precise landing/hazard avoidance GN&C algorithms: safe landing on Venus 

— Rovers and other low-speed vehicle GN&C algorithms: balloon ascent for Venus ascent 
vehicle prior to rocket ignition. 

• Highly enhancing technology requirements 
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— Continuous low thrust trajectory design algorithms: to reduce the cost of SEP return 
flight. 

• Enhancing technology requirements 

— Continuous low thrust GN&C algorithms: accurate SEP flight path estimation and 
control. 

Saturn Ring Observer 

• Autonomy capability needs 

— Opportunistic science while in orbit above ring plane 

— Data compression 

— Low-cost operations during long-duration cruise phase 

— Autonomous onboard retargeting for science operations. 

• Highly enhancing technology requirements 

— Instrument data processing to perform aerocapture cleanup and maintain hover orbit. 

• Enhancing technology requirements 

— Onboard planning and execution for opportunistic science operations and low cost 
operations 

— Monitoring and diagnosis: migration of routine monitoring functions for long cruise 

— System software: low cost operations to reduce operations cost for long cruise period 

— Instrument data processing: achieve lOx increase in data value for fixed downlink 
volume, autonomous retargeting for increased science return. 

• Guidance, navigation, and control capability needs 

— Accurate, fuel efficient, low-cost cruise 

— Accurate approach phase navigation 

— Flight path estimation and control during aerocapture 

— Station keeping above the ring plane 

— Efficient SEP or solar sailing trajectory design algorithms. 

• Highly enhancing technology requirements 

— Continuous low thrust trajectory design algorithms: reduce propellant usage for SEP 
option 

— GN&C algorithms for near planetary ring system: stationkeeping and formation flying 
relative to the ring plane to a vertical accuracy of 0.5 km 

— Aerocapture/aeromanuevering GN&C algorithms: aerocapture into a bound orbit about 
Saturn. 

• Enhancing technology requirements 

— Delta V efficient trajectory design algorithms: minimize delta-V expenditure during 
hovering and traversing activities near the ring plane 

— General cruise, approach, and on-orbit GN&C algorithms: accurate, low-cost navigation 
during cruise and on approach to Saturn 

— Continuous low thrust GN&C algorithms: accurate flight path estimation for imprecise, 
low-level SEP thrusting. 
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3.4.4 Summary of ESS Information Technology Needs 
The ESS mission IT capability needs are shown in Table 3-5. 

Table 3-5. ESS Mission IT Capability Needs 

Autonomy and Control 


Mission Capability 


SA/V Systems for Low 
Cost Ops 

H. Enhance 


Enhancing 


Enhancing 

Enhancing 

Enhancing 

Safe Landing Systems 


Enabling 

Enabling 

Enabling 



Enabling 

Intelligent Sensing 




Enhancing 



H. Enhance 

Rendezvous & Docking 


Enabling 


Enabling 




Onboard Planning & 
Execution 

Enhancing 

Enabling 




Enhancing 

Enabling 

Instrument Data 
Processing 

Enhancing 

Enabling 

Enabling 

Enabling 

Enhancing 

HI. Enhance 

Enabling 

Monitoring & Diagnosis 

Enhancing 

Enhancing 

Enhancing 

H. Enhance 

Enhancing 

Enhancing 

H. Enhance 


Guidance, Navigation & Control 


Mission Capability 
Needs 

pill- 


| Luroua 

, 

Nii 


Sjtum 


Efficient Traj. SW 

Enhancing 


H. Enhance 



Enhancing 


Cont Low Thrust SW 


H. Enhance 


H. Enhance 

H. Enhance 

H. Enhance 

H. Enhance 

General Auto Nav 

Enhancing 

Enhancing 

Enhancing 


Enhancing 

Enhancing 

Enhancing 

Continuous Low Thrust 


Enabling 


Enhancing 

Enabling 

Enhancing 

Enabling 

Near Small Body 


Enabling 






Near Planetary Ring 






Enabling 


Rendezvous & Docking 


H. Enhance 


Enabling 




Aerocapture/Aeroman . 




Enabling 

Enabling 

Enabling 

Enabling 

Safe Landing 


Enabling 

Enabling 

Enabling 



Enabling 

In-situ Vehicles 




Enabling 



Enabling 
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3.5 Sun-Earth Connection (SEC) 

The goal of the Sun-Earth Connection Theme in the Space Science Enterprise is an 
understanding of the changing Sun and its effects on the Solar System, life, and society. SEC’s 
strategy for understanding this interactive system is organized around four fundamental quests 
designed to answer the following questions: 

• Why does the Sun vary? 

• How do the planets respond to solar variations? 

• How does solar variability affect life and society? 

• How do the Sun and galaxy interact? 

SEC’s challenging science program involves: (1) Seeking breakthroughs in understanding by 
making measurements from new vantage points within and outside the Solar System; (2) making 
simultaneous, system-wide measurements with constellations of spacecraft that resolve existing 
space-time ambiguities; and (3) applying new scientific knowledge strategically to produce 
direct and immediate benefits to our increasingly space-dependent society. 

There are two programs or lines of spacecraft that are of primary importance to SEC: the Solar 
Terrestrial Probes , a series of independent missions each focused on specific science goals; and 
the Living With A Star Program, a set of missions designed to provide system-wide 
understanding of the variable Sun and its dynamic effects on geospace. 

3.5.1 Solar Terrestrial Probes 

Magnetospheric Multiscale (MMS) 

MMS, scheduled for launch in 2008, will explore and understand reconnection, particle 
acceleration, and turbulence on micro- and meso-scales to determine the flow of energy, 
momentum and mass within and across plasma boundaries in the Earth’s magnetosphere. MMS 
will fly at least four identically-instrumented spacecraft in a tetrahedral formation to distinguish 
between spatial and temporal effects and to resolve the three-dimensional structure of the 
processes under study. 

Control of the cluster of four spacecraft is a vital aspect of the mission design, with orientation 
control of the formation required to 15° and knowledge of the position of the spacecraft needed 
at 1% of the interspacecraft spacing. With the minimum spacecraft separation on the order of 10 
km, this will require knowledge of the spacecraft position as precise as 100 m, in regions of 
space well above GPS. Ground tracking, interspacecraft ranging, and advanced techniques that 
make use GPS at high altitudes are all under consideration for this mission requirement. 

Geospace Electrodynamic Connections (GEC) 

GEC mission, scheduled for launch in 2009, is a 2-year mission that will place three or four 
spacecraft into a high-inclination elliptical orbit with an apogee of 2000 km and a perigee of 185 
km. The spacecraft will be identically-instrumented for in situ sampling of the ionized and 
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neutral gases of the upper atmosphere and measurement of the electric and magnetic fields that 
couple this region to the magnetosphere. 

The formation of spacecraft will periodically lower their perigee, perhaps as low as 130 km, to 
dip into the upper atmosphere. It would enhance the mission (and help maintain low operations 
costs) if these dipping campaigns could be automatically triggered by solar or geomagnetic 
activity. In the absence of orbit-raising maneuvers, spacecraft orbits would decay within just a 
few days. It would be highly enhancing to have a robust, on-board, autonomous safing system 
that would maintain the spacecraft orbit without the need for ground intervention. Also desired 
are systems that make optimal use of spacecraft propellant, as ultimately it is a resource that will 
likely be mission limiting. Pointing control and aerodynamic stability during dipping are also 
important for optimal science return and efficient consumption of propellant. 

Magnetospheric Constellation (MagCon) 

MagCon mission, scheduled for launch in 2011, will be a distributed network of space weather 
observatories. Comprised of 50-100 nanosatellites, the constellation will acquire vector 
“images” of the magnetic and plasma flow fields in Earth’s magnetotail. Placed in high-altitude, 
elliptical orbits with a dense sampling from 7—40 R e , MagCon will resolve space-time 
ambiguities that now limit the insight possible from single-spacecraft measurements. 

MagCon poses a number of challenges for information technology. Design, manufacture, and 
test tools for constellations of fifty or more scientific spacecraft will be required, especially in 
view of the modest unit cost (~$1.5M per instrumented spacecraft) envisioned. Previously, 
fields and particles instruments have been meticulously constructed, tested, and calibrated, but 
for MagCon, automated calibration of scores of magnetometers and other instruments will be 
required. 

MagCon spacecraft will rely on body-mounted, solar arrays and as such will be profoundly 
power-limited. As a result, ultra-low power systems for control and data handling and high- 
altitude X-band communications will be needed. As these spacecraft will be out of 
communication with the ground for days at a time, these systems must be tolerant of the 
radiation environment and deal autonomously with environmental upsets or other faults. 
Similarly, onboard processing that adaptively manages the instruments and maximizes the 
science return using available onboard storage and downlink. 

For MagCon, methods and techniques for planning, managing, and controlling single spacecraft 
must be significantly adapted or wholly re-invented to deal with 50+ spacecraft. Systems that 
assist mission planning (providing guidance regarding orbital placement that maximizes science 
return) and ground operations (autonomous systems that provide health, safety, and commanding 
for each spacecraft). Information systems that gracefully accommodate the inflow of data from 
the constellation must be developed. This system must provide for seamless input and 
comparison of data with circulation models, as well as visualization techniques that aid 
understanding by scientists, and that communicate the exciting nature of this complex science to 
the layman. 
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3.5.2 Living With a Star Missions 

Solar Dynamics Observatory (SDO) 

SDO, scheduled for launch in 2006, will fly a three-axis stabilized spacecraft in geosynchronous 
orbit with a complement of solar-pointed instruments to make continuous, high-cadence 
observations of the Sun from its subsurface layers to its outer atmosphere. Obtaining such data 
throughout the better part of an 1 1-year solar cycle will vastly improve understanding and 
forecasting of the Sun’s impact on the terrestrial environment. 

SDO will transmit a continuous stream of high-resolution images of the Sun (in various 
wavelengths) and of the solar corona. The system is envisioned to be highly reliable, and thus 
consistent with a 7-year mission goal. Some customers may be interested in real-time 
capabilities (likely using ground processing) further enhancing the need for robust, reliable space 
systems. A high-bandwidth, data distribution, and management system will be needed to 
accommodate the SDO data rate (-100 Mbit/s), onboard processing of the data. 

Missions to study the effects of the variable Sun on geospace are presently under review by the 
LWS science architecture team, in cooperation with the LWS program and the Geospace mission 
team. At this stage, it is clear that information technology that enhances the geospace elements 
of the program, which may be smallsats or merely instruments flown on other non-LWS 
platforms, will be keenly sought. Areas of interest include integration of data into new, physics- 
based models of geospace, systems for coping with severe environments such as the radiation 
belts, and data systems that account for the likely disparate nature of collection platforms. 

Sentinels 

Sentinels, scheduled for launch in 2009, will consist of several spacecraft that globally 
characterize the heliosphere between the Sun and Earth. The measurements are intended to: 1) 
enable improvement of the models of transient propagation (such as coronal mass ejections) and 
2) resolve geo-effective solar wind structures so that they may be traced back to solar features or 
phenomena (thus improving long-term predictive capability). These are envisioned as small 
spacecraft operating in deep space, making coordinated in situ measurements of the heliosphere 
and possibly remote sensing of the Sun. 

3.5.3 Strategic Missions 

Solar Probe (SP) 

SP, a mid-term strategic mission in the SEC Theme, will venture deep into the solar corona, the 
Sun’s outer atmosphere — far closer to the Sun than any other spacecraft has previously ventured. 
It will make in situ and remote measurements at 3 solar radii above the solar surface, where its 
shield temperatures will exceed 2,000 K. This mission must cope with the multiple challenges of 
the near-solar environment (photons, thermal, radiation, dust) as well the Jovian environment 
during gravity assist (low intensity of photons, radiation). Spacecraft systems for Solar Probe 
will be highly specialized, and must be extremely robust and reliable. 
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Solar Polar Imager ( SPI) 

SPI, a mid-term strategic mission, will study the physics and dynamics of coronal mass ejections 
and other eruptions from the surface of the Sun. The mission concept envisions use of solar sails 
to leave the ecliptic plane and propel a spacecraft into a circular polar orbit around the sun. 
Systems that autonomously guide the solar sail-equipped spacecraft will be required. 

Reconnection and Microscale Probe (RAM) 

RAM, a mid-term strategic mission, will do full-disk imaging of the Sun and complementary, 
ultra-high resolution (0.02 arc-sec) coronal imaging. The spacecraft is envisioned to require 
continuous and burst RF systems from operations at geosynchronous or LI, and to make use of 
autonomous feature/event recognition to guide its imaging of dynamic phenomena on the Sun. 

Interstellar Probe (ISP) 

ISP, a long-term strategic mission, plans to explore the region beyond the heliosphere, indeed 
well out into interstellar space. Using advanced propulsion (a solar sail is the current baseline), 
the mission envisions sending a spacecraft to 200 AU in 20 years or less, in a direction upwind 
of the Sun’s motion with respect to the galaxy. This is certainly a high-technology mission 
concept, with needs for an advanced, high-temperature-capable solar sail (a solar approach at 
0.25 AU helps achieve high velocity); Ka-band and/or optical communications from deep space; 
miniaturization of a fields and particle instrument suite that would also have unprecedented 
sensitivity; and system architectures that yield ultra-high reliability thus enabling mission 
lifetimes measured not merely in years but in decades. 

3.5.4 Summary of SEC Information Technology Needs 

The SEC mission IT capability needs are shown in Table 3-6. 
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Table 3-6. SEC Mission IT Capability Needs 

Mission 

i Need 

* 

date Item 

Impact 

Description 

TSG 

Database 
Record No. 

MMS 

i 

2005 'Constellation 
^control 

Highly 

enhancing 

5 s/c in loose tetrahedral configuration; poosition 
knowledge 1% separation (as low as 100m); 
'orientation to 1 5° 

1120 

{ 

;MMS 

i 

5 

; 2005 Phased array 
•antenna 

Enhancing 

Phased-array antenna for spinning spacecraft; X- 
band, 1 .5 Mbps at 100 Re 

1134 

tmms 

\ 

i 

2005 On-board 

‘computation 

i i i 

Enhancing 

-5000:1 compression of distribution functions 
(plasma) + >1 00:1 compression to broad band 
field data. Parallel to IRAD 6000 baseline. 

1397: 

f 

r 1 

|gec 

i 

2006 Formation 
control 

Highly 

enhancing 

Automatic maintenance of orbit;automated 
commencement of dipping campaigns triggered 
by geomagnetic activity; autonomous 24/7 
'control of spacecraft. 

1411! 

i 

i 

5 

iGEC 

1 

2006 Aerodynamic 
stabilityand 
| ^control 

Highly 

enhancing 

Aerodynamically stable during dipping. Point 
within 2° from ram to ensure low drift and neutral 
;wind measurement. 

1 41 6"’ 

i 

£ MC 

j 2008 Automated 
j 'calibration of 

| jconstellation 

; magnetometers 
and other 

Highly 

enhancing 

Automated calibration of constellation 
magnetometers. Cost consistent with $1.4M 
instrumented spacecraft unit cost. 

1 1 1 4 1 

t \ 

i 

;MC 

2008 Fault-tolerant, 
avionics 

Highly 

enhancing 

Autonomous, graceful recovery from upset. Fault 
detection, correction. 

1166; 

MC 

’ 2008 Design, 

manufacture, 
jand test tools for 
! constellations 

Enabling 

50 nanosats each with 3 scientific instruments. 
$1.4 M total unit cost for spacecraft 

Wf 

MC 

2008 Calibration of 

i • 

Magnetometers 

Highly 
? enhancing 

Automated calibration of constellation 
magnetometers. Cost per unit calibrated (TB 
studied) 

1114: 

MC 

2008 Ultra-low power 

:c+dh 

subsystem 

Enabling/ 

Highly 

enhancing 

Enabling - 0.5 kg, 1.6W.1 00 kRad Si (total 
dose), instrument rate 10 kbit/s, 4 Gbit storage , 
CCSDS uplink/downlink protocol, 1 kbit/s uplink, 

1197,1455; 


640 kbit/s downlink (max); centralized data 
processing for all instruments and ACS sensors 
integrated with spacecraft electronics. 
Consistent with 50 spacecraft, 20-kg, 20-W, $1 .4 
M unit spacecraft cost. Highly enhancing - 0.25 
kg, 0.8 W, 1 00 kRad Si (total dose), instrum ent 
rate 10 kbit/s, 4 Gbit storage , CCSDS 
uplink/downlink protocol, 1 kbit/s uplink, 640 
kbit/s downlink (max); centralized data 
processing for all instruments and ACS sensors 
integrated with spacecraft electronics. 
Consistent with 100-spacecraft, 10-Kg, 10-W, 
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Mission 

Need 

date Item 

i 

Impact Description 

TSG ! 

; Database 
Record No. 

MC 

. 2008 Ground-based 
; autonomy 

Enabling Automatic control and monitoring of a 50 to 100- 
spacecraft constellation 

1218 

MC 

! 

2008 X-band 

transponder 

? j 1 

; i 

? 

Enabling/ Enabling - STS transponder: receiver data rate - up to 
Highly 4 Kbps; transponder data rate >1 Mbps; 0.15 kg, 6 
enhancing WRF T ransponder, generate signals for orbit 

determination. Resources consistent with 20-kg, 20- 
W, $1 .4 M spacecraft. Highly enhancing - STS 
transponder: receiver data rate - up to 4 Kbps; 
transponder data rate >1 Mbps; 3 W, 0.15 kg 
generate signals for orbit determination 
Resources consistent with 10-kg, 10-W, $700 K 
spacecr 

1 

1223,1457. 

j ; 

\ 

i i 

iMC 

2008 Orbit placement & 
determination 

1 . . ! 

i : 

; j j 

Enabling Initial control of apogee ± 0.5 Re; knowledge ± 20 
km, ?v = 1000 m/s, cost, mass production 
compatible with 20-kg, 20-w, $1.4M spacecraft 

1412 

ISP 

far-term 3-D models of 
solar sail 
interactions with 
solar wind/plasma 
environment. 

Enhancing 3-D Particle in a Cell computer code for modeling 
large solar sail interactions with space environment. 

1376, 

ISP 

far-term Ka-Band 
Frequency 

Enhancing IkW Ka -Band uplink transmitters. 

iiM 

^isp 

far-term Ka-Band SSPA 

Enhancing -50% DC to RF efficiency 

; “l?37 

r ISP 

i 

i 

far-term Pointing systems 

• t 

Enhancing Lightweight, minimally intrusive instrument to validate 
far-field antenna pointing to 0.02° from near-field 
antenna pattern. 

r ” 1139 

ISP 

i 

i 

far-term Optical 

Communications 

Enhancing Flight-qualified, lightweight optical communications 

transceiver terminal. Integrated telescope and deep 
space optical communications ground receiver 
systems. 

1140 

ISP 

far-term Ground 

telescopes 

Enhancing Low-cost, 1 0-m class ground telescopes. 

1142 

ISP 

far-term Space Laser 

j i 

Enhancing 1 5-W avg Q-switched power IR lasers (900-1 1 00 
nm) with > 20% wall plug efficiency, spatial beam 
quality - 1 ,2x diffraction limit.. 

1143 

ISP 

far-term Avalanche 
Photodiodes 

Enhancing High (IR) quantum efficiency (> 0.8), high gain 
(>100), low noise APDs. 

1144 

ISP 

far-term Space telescopes 

Enhancing Light weight, thermally stable telescopes 0.3-0. 5 m, 
< 6 kg, Primary mirror < 1/8 wave RMS WFE 

1146 
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w 

Mission 

Need 

date Item 

Impact 

Description 

TSG 

Database 
Record No. 

V-/ 

ISP 

far-term Communications 
Testbed 

Enhancing 

Deep-space optical communications testbed. 

1159 

W 

ISP 

far-term Propagation 
Models 

Enhancing 

Develop propagation models for optical 
communications links that include all of the 
atmospheric factors 

1381 

w 

w 

ISP 

s 

far-term Fault-tolerant 
avionics 

Highly 

enhancing 

Fault tolerant architecture for 30-year mission. 

1170 

V 

V 

[ram 

s 

1 

mid-term Continuous and 
Burst RF 
Systems 

Enhancing 

(RAM) 5-10 Mbytes/s burst downlink from LI (or 
GEO). /2003-2007/ ENHANCING. 

1132 


;RAM 

mid-term Feature/event 
Recognition 

Enhancing 

(RAM) On-board Al event processing /2008-2014/ 
ENHANCING. 

1281 

V 

V 

GSRI 

far-term 3-D models of 
solar sail 
interactions with 
solar wind/plasma 
environment. 

Enhancing 

(GSRI) /2015+/ ENHANCING. 

”984; 

i { 
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4. NASA Information Technology Research and Development 

This chapter provides a broad review of the current information technology research and 
development activities being supported by NASA along with information about the funding for 
these programs from both OSS and from OAT. The first subsection provides a detailed 
description of the technical scope of the work being performed while the second subsection 
provides detailed budget information about the various funding sources for these activities. 

Technology Area Descriptions 

A total of five technology areas were identified in this study to help subdivide the problem. This 
division attempts to emphasize areas where NASA has a unique need within the broad area of 
information technology. 1 The five areas identified were: 

1. Reliable software engineering. Technologies that assist in the cost effective development, 
testing, verification and validation of large software systems that are highly dependable and 
meet the mission requirements. 

2. Highly robust autonomous systems. A broad range of technologies designed to enable 
smarter, more adaptive systems that can respond to uncertainties in the environment while 
attempting to achieve a set of high-level goals and objectives. 

3. Computing, communications, and distributed computing. Technologies that provide 
increased computational resources, networking and communications. This includes more 
capable single processor systems, parallel computers and distributed networks both for 
terrestrial and space applications. 

4. Virtual mission lifecycle. Technologies that advance the mission lifecycle process by 
providing evolutionary mission information systems, comprehensive design verification and 
validation, concurrent lifecycle phase engineering, and effective work-flow between teams as 
well as between human and machine. The IT efforts are categorized as virtual mission 
lifecycle IT. The term virtual reflects the technical approach emphasizing software- oriented 
modeling and simulation to create representations of real missions. These technologies assist 
in mission design and development. 

5. Science data processing, access, analysis, and knowledge discovery. Technologies designed 
to assist scientists on the ground process, analyze, and manage the large amount of data 
collected by NASA missions. The technologies described here are critical in supporting the 
scientific and discovery process. 

A number of technologies often span one or more of these technology areas. For example, data 
analysis and knowledge discovery software is available both on the ground to assist scientists as 
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Trying to define and scope the term information technology is difficult due to the systemic nature of information technology and the degree to 
which it is often closely coupled to the development of other technologies. This assessment did not attempt to rigorously define this term since 
such a definition has limited value with respect to addressing the mission needs of OSS. As such, some of the activities described within this 
section might be more appropriately classified under other technology areas. In general, we tried to err on the side of being inclusive of activities 
that are closely related to information technology. 
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well as onboard within the real-time control loop. In general, when there was overlap both 
sections made at least some reference to ongoing work. However, we attempted to define the 
boundaries in a manner that minimized some of this overlap. 

For each of these technology areas, an additional breakdown is provided that divides the areas 
into smaller subtopics. The description of these subtopics starts with a description of the 
capabilities that are provided by this technology area, followed by a description of the 
technologies that provide these capabilities and finally a sampling of some of the products that 
are being developed within the NASA IT program. Note that a comprehensive list and 
description of every product was outside the scope of this report. 

4.1 Reliable Software 

4.1.1 Overview 

Software is the building material of information technology. Software reliability is as crucial to a 
space mission as the failure strength, temperature robustness, and other properties of the 
materials out of which a spacecraft is built. Software reliability is an overarching requirement 
that cuts across all missions, rather than mapping to particular aspects of specific missions. The 
consequences of software failures for space missions can be much more severe than software 
failures in commercial industry. Billions of dollars have already been lost due to software-related 
mission failures. Furthermore, space mission software has historically been unique, and hence 
has not benefited from the massive amount of de facto testing performed by early adopters of 
commercial software. Space mission software must work right the first time it is executed ‘in the 
field’. Although an increasing trend is the reuse of previous mission software, the reuse of space 
mission software that was not designed for reuse can be disastrous - as happened in the reuse of 
the Ariane 4 state estimation software in the Ariane 5. 

Software reliability is a necessary precondition for achieving the benefits of other advanced 
information technology, such as autonomy. The dilemma faced by NASA is that to achieve the 
future mission-enabling and cost-reducing potential of advanced information technology it must 
achieve far higher levels of software reliability on much more complex software than it has 
achieved on comparatively simple mission software in the past. This poses challenges ranging 
from improvements of software engineering management, to technology for verifying complex 
software where testing coverage is infeasible, to automation of labor-intensive and error-prone 
aspects of software development. 

The aerospace industry, like most other industries, is seeing increasing importance in the role 
played by software: the amount of software in a mission is steadily increasing. This has 
delivered benefits: more functionality, both in absolute terms and in the percentage of overall 
functionality that is performed in software; and it is faster, easier, and cheaper to correct a 
software problem than to redesign a hardware fix. Software is comparatively easy to change to 
adapt to changing requirements, and software can even be changed after launch, making it an 
especially versatile means of achieving mission goals. 

Table 4-1 provides historical data from a small number of space missions, and gives flight 
software in thousands of lines of source code. Note that while Cassini and Pathfinder launched in 
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the same year, development of Cassini started many years earlier. The data clearly indicates an 
w exponential growth over time in the size of flight software. This exponential growth is consistent 

_ with other sectors of aerospace including civilian aviation and DoD. 


v Table 4-1. Flight Software Lines of Code for 

Representative Missions/Systems 



Mission 

Launch Year 

Thousands SLOC 

V/ 

Voyager 

1977 

3 


Galileo 

1989 

8 


Cassini 

1997 

32 


Mars Pathfinder 

1997 

160 

O 

Shuttle 

2000 

430 

- w 

ISS 

2000 

1700 


Challenges 








V 


However, the result of this increasing dependence is that software is becoming a weak link in 
space mission engineering. NASA’s problems are not unique: the data across all industries show 
that many projects have been cancelled or late due to software cost and schedule overruns. And 
some of the projects that have been completed have suffered fatal losses due to software errors. 
The Standish Group study on software projects across government and commercial projects 
found the following statistics on success rates and adherence to the original development plan: 

• 16% On time and on budget 

• 31% cancelled (mostly due to overruns where the prospects for success become dim) 

• 53% late and over budget 

• Average cost growth: 89% above original plan 

• Average functionality: 61% of original plan. 

Thus, NASA is not unique either in its increasing dependence on software nor in its problems 
with software engineering. However, it does face greater challenges than is typical for 
commercial software engineering, such as the need for software to work reliably the first time it 
is deployed. The software challenge for OSS is multi-faceted: 
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• Avoid mission failure. Software errors during critical mission phases such as launch, entry, 
descent and landing - and for critical functions such as navigation - have led to a series of 
mission losses. 

• Avoid loss of mission function/loss of science data. A rover asset on Mars has an amortized 
cost of millions of dollars a day. Even software failures that only temporarily disable a space 
asset are costly. 

• Reduce the cost to a mission for software development. 

• Reduce the time and schedule required for software development. 
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• Enable new mission capabilities through advanced IT technology by ensuring that the 
software has sufficient reliability to be incorporated into missions. 

• Scale up software development technology and processes for future software growth. 

These challenges are interrelated. At any stage of maturity of software engineering technology 
and process, the multiple criteria of reliability, cost, and schedule can be traded off against each 
other (within limits). For example a mission manager might choose to compress development 
schedule by increasing overall manpower; the empirical data indicates that this increases total 
work-years and, hence, cost. As another example a manager might limit the number of design 
and code reviews and incur greater risk of overlooking a mission-critical software error. The 
imperative of ‘faster, better, cheaper’ is to lift the tradeoff curves through development of better 
technology, methods, and processes. 

In the remainder of this overview we discuss the challenges facing OSS, explain quantifiable 
models and their bases, and then extrapolate these models to the future. We then provide a 
synopsis of how NASA IT investments map to these challenges, which is expanded in 
subsequent subsections. 

The scope and complexity of NASA missions is rapidly increasing. Much of the advanced 
capabilities of these missions are embedded in the flight and ground software used by those 
missions, hence the increase in the size of the software. The empirical data on software 
development cost and schedule as it relates to increasing size and complexity has been 
extensively studied by Barry Boehm. Boehm has developed mathematical models of cost and 
schedule drivers that have been statistically validated and calibrated. The models indicate a 
super-linear growth in cost and schedule with the increasing size of software, hence we should 
expect an accelerated exponential growth in cost and schedule for mission software in future 
years without corresponding changes in technology and methods. In Boehm’s model, a main 
factor for this super-linear growth is the cost and time to fix unintended non-local interactions: 
that is, unintended interactions between separate software components and unintended 
interactions between software and systems. 

Models 

Quantifiable data on software reliability is more difficult to obtain than data on software 
development cost and schedule. (Indeed, some of the research projects described below have the 
goal of determining what data should be kept by missions so that we can develop better models). 
However the record of conclusions from mission failure review boards clearly indicates that 
unintended non-local interactions is also a main driver for fatal software errors and software- 
related system errors: 

• MCO was most likely lost due to unit mismatch between separately developed navigation 
software and navigation data. 

• MPL was most likely lost due to unintended interactions between landing probe touch sensor 
activation on deployment and variable initialization in the software for the landing phase. 
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• A recent Titan launch most likely failed due to the interaction between an unintended 
oscillation of a rocket nozzle (induced by control software) and the eventual complete loss of 
non-recirculating lubricating fluid. 

• Ariane 501 most likely failed due to unintended interactions between state estimation 
software (reused from Ariane 4) and the higher velocities achieved on Ariane 5 (versus 
Ariane 4). 

Both the empirical cost/schedule data and the record on failures are readily understandable: as 
the size of software systems increase (and the number of elements which interact increases 
proportionally) the number of potential interactions between elements grows quadratically. 
Tracking down these interactions is complex and difficult, fixing bad interactions without 
introducing new errors takes time and money, and the consequences of not fixing unintended 
interactions can be fatal. We thus extrapolate Barry Boehm’s schedule/cost model to an 
analogous model for software reliability. The model is based on proportional factors of expected 
interactions between components as software size increases. If every one of S components 
interacted with every other one there would be S 2 interactions. Fortunately, the interactions are 
more sparse; the best calibration over many projects gives an exponent of 1.2 as indicated by 
growth in cost and schedule. The data also indicates that improvements in software process not 
only reduce the total number of errors but also the growth in errors as software size increases. 

For software projects with high levels of process maturity, the exponent is 1.1. This makes sense: 
better engineering management gives a handle on unintended interactions through better 
communication and coordination across the development organization, as well as better 
documentation. 

In Figure 4-1 we show the number of predicted mission-critical errors versus size of mission 
software {LOC - lines of source code), on a log-log scale. We assume that the number of errors 
is proportional to ( S/M ) N , where S/M is the number of components (modules), computed as the 
number of source lines of code divided by the lines per module. For the baseline model, we take 
the number of lines of code per module, M, to be 100. For this baseline model the exponent N is 
assumed to be 1.2. The model is calibrated with an assumption of a 40% probability of a critical 
software error at 100K SLOC, based on recent deep space missions. (More specifically, the 
vertical axis is interpreted as the mean number of expected critical software errors.) This is a 
conservative estimate based on recent missions including Mars Polar Lander, Mars Climate 
Orbiter, and Mars Pathfinder. 
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This model indicates that the probability of critical errors is small with systems under 100K 
SLOC, but grows considerably as the size grows towards what is expected of future missions 
incorporating advanced information technology. Cost and schedule metrics are proportional to 
the predicted errors under this model. The technology challenge for OSS software reliability is to 
develop methods for managing complexity as software size increases, particularly for future 
systems incorporating advanced information technology. Without improvements in methods or 
technology, this model predicts very little chance of a successful mission significantly beyond 
the 100K SLOC level. Of course, there are many examples of commercially-viable software 
systems that are much larger than 100K SLOC. However, commercial viability is a much lower 
standard of reliability, and in fact the first deployment of a commercial system seldom has fewer 
critical errors (an error that can potentially crash the system) than predicted in this graph. 
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Figure 4-1. Lines of Code versus Mission-Critical Errors 


The rest of this section is organized according to the various strategies for increasing software 
reliability shown in Figure 4-2. Managing Complexity means reducing the slope of the line by 
reducing the factor N. Scaling-up S/W Engineering (Computer-Aided) means shifting the line 
over to the right by enabling developers to produce more software than the mostly manual 
process prevalent today. Detecting Errors means shifting the line down by improving the 
verification and validation (V&V) process. Finally, tolerate errors means being able to detect 
and recover from errors that occur at runtime. We believe that all these strategies will need to be 
combined synergistically in order to achieve the needed reliability for NASA’s future robotic 
space missions. 



Figure 4-2. Strategies to Increase Software Reliability 
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4.1.2 Managing Complexity 

In this subsection we describe organizational mechanisms for managing complexity, and hence 
reducing the expected super-linear growth in errors versus growth in software size. The first 
mechanism is software architecture: a framework or superstructure for developing a software 
system, in which the interaction patterns between subsystems have already been validated. A 
good software architecture will also enable decomposing verification and validation tasks, 
precisely because the interaction patterns between subsystems had already been validated in the 
framework. The second mechanism is software process: the organizational and management 
procedures followed in developing the software. Software process is currently the most widely 
used technique for assuring software quality. A good software process ensures that the 
development organization uses procedures for examining non-local interactions between 
components that have been developed separately. 

4.1.2.1 Capabilities for Managing Complexity 
Capability Provided by Robust and Verifiable Architectures 

Until recently, deep space missions tended to be one-of-a-kind, with distinct science objectives, 
instruments, and mission plans. Even though missions shared many recurring tasks, such as 
telecommunications, commanding, attitude control, and navigation, they were spaced years 
apart, so software was developed independently for each mission. Software design has also been 
limited by available radiation-hardened flight computers, which are typically years behind their 
commercial counterparts in speed and memory (if there were any counterparts at all). This 
fostered an approach to software, highly tailored and optimized for each mission, with wide 
disparities between flight and ground approaches. It also limited performance and science 
returns, and consequently the types of missions that could be launched. 

We are entering a new era of Solar System exploration. In order to enable this next generation, 
mission software will have to accommodate more complex, autonomous science, and easy 
infusion of new technologies. Yet there is also a demand for smaller, lower-cost deep space 
missions. Automation is essential to lowering operations cost, by easing demand on both 
operators and telecommunication facilities, but future efforts will also require reusable software. 
Unhappily though, there has been no common framework for developing mission software and 
little software reuse. Each mission either builds software from scratch or tries to reuse software 
that was never designed for reusability. This introduces unnecessary risk and cost on every 
project. Furthermore, increasingly complex mission software places unprecedented demands on 
systems engineering to specify what systems must do and on software engineering to create 
systems that work. While recent enormous growth in onboard computing capability has made the 
required complexity possible, the result is a widening gap between systems and software 
engineering. Bridging this gap is also a vital component of successful mission software solutions 
for the future. 

Our challenge, then, is to design reliable software that expands mission capabilities and that can 
be reused efficiently and effectively in various mission scenarios. The architectural design of a 
system describes, at a relatively coarse granularity, the main components/modules of the system, 
the interfaces they expose to other components, and the way they interact to fulfill the system 
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requirements. It offers the capability to make and assess design trade-offs early in the 
development of a system, and to detect integration problems at design time. It enables 
verification to be decomposed hierarchically. Architectural designs can also be developed for 
families of products, such as software for deep-space missions, capturing commonalities across 
products and across different subsystems within the same product. An architectural approach 
therefore provides guidelines to increase reusability across product families, or during evolution 
of a single product. 

There is no predefined level of abstraction at which architectures are best defined. In fact, 
architectures are typically specified as hierarchies of components thus defining several levels of 
abstraction. An architecture for product families may include models of components or even 
code for components. Parts of a system may also need to be partially specified. 

In terms of verification, architecture is an enabling capability for incremental and compositional 
reasoning. These are “divide and conquer” techniques that may significantly increase the 
scalability of exhaustive verification (see Section 4. 1.4.2). It may also describe or imply the 
properties that components must satisfy in the specific framework in which they will be 
introduced. 

Capability Provided by Software Process 

Software process is the engineering management of software design, development, test, and 
maintenance. Lack of adequate software process is often identified as one of the causes in 
mission software failures, and process improvement is one of the principle ways of improving 
software reliability in the near term. It is also a principle vector by which future reliability 
technology can be deployed. Process is required to ensure that a given project is completed on 
time, within budget, and with appropriate quality. Process is also the basis of repeatability and 
institutional improvement, because process is where institutional knowledge about the 
programmatic aspects of software development are formally captured and evolved. Process is 
how the capabilities of individuals are infused into the capabilities of the institution as a whole. 
As NASA undertakes the construction of ever larger and more complex software systems- both 
for flight and ground - process will remain important as a key success factor. 

The NASA Software Strategic Plan addresses the importance of software process. Goal 1 in the 
plan states, “...Implement and integrate software engineering processes into systems engineering 
on NASA programs. ...,” and Goal 3 states, “Continually improve NASA's software engineering 
processes to produce measured improvements in the cost and the quality of software developed 
for and by NASA.” 

A significant process capability is independent verification and validation (IV&V). This is a 
conscious organizational separation of the cost and schedule drivers to which development 
organizations must respond from the quality drivers and adherence to safe processes that are 
needed for mission assurance. IV&V provides an independent oversight role to assure adherence 
to safe practices; for NASA this is provided by the IV&V facility headquartered in West 
Virginia. 
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4. 1.2.2 Technologies for Managing Complexity 
Technologies for Robust and Verifiable Architectures 

Software architecture technology includes languages and frameworks for the expression of 
system architecture, methods for the incremental refinement and instantiation of an architecture 
to a particular system, and methods for checking the consistency of an architectural definition 
both at the syntactic level and the behavioral level. Unified Modeling Language (UML) provides 
some of the notations necessary for expressing software architectures, though more rigorously 
defined architecture description languages provide a firmer foundation. At the behavioral level, 
compositional model checking is a technology for verifiable architectures. In compositional 
model checking the required system properties are decomposed into required properties of their 
components. The architecture provides the structure for this decomposition, and this 
decomposition can be verified prior to instantiating any particular component. The verification 
task that remains when instantiating a system according to the architectural pattern is to verify 
that each component satisfies its required properties, using an assume-guarantee methodology. 
Compositional verification in general is a “divide and conquer” technique that may significantly 
increase the scalability of both homogenous and heterogeneous verification methods. 

Software Process Technology 

The technology for software process consists of validated methods for software engineering 
management. This includes adapting methods to incorporate new software engineering 
technology. To date, the most widely accepted process guide is the Capability Maturity Model, 
developed by the Software Engineering Institute at Carnegie Mellon. This model measures how 
well a software development team operates, using accepted best practices for each phase of the 
development process. NASA does a good job of applying best practice processes to most of its 
software development projects, but there is room for some improvement. The model has 5 CMM 
levels; recently NASA directed each Center to achieve CMM level 3 on its software projects. A 
new model, CMMi, addresses process issues for both software and systems engineering, and is 
being adopted by some NASA centers that wish to go beyond CMM. Technology for software 
process includes management guides, measurement metrics, and institutional capabilities 
available to NASA. Technology research and development for software process is being carried 
out in various NASA laboratories, as well as in pilot studies. 

4.1.2.3 Products for Managing Complexity 
Products for Robust and Verifiable Architectures 

Scalable Verification Technology for Autonomy Architectures ( Ames-TRL 3 FY02) 

This technology development is focused on scaling up formal verification for large (100K SLOC 
or more) autonomy software systems. Examples include the MDS reference architecture and the 
Ames Rover executive. The research is also aimed towards identifying features of architectures 
that make them more amenable to verification (hence the term “verifiable architectures”). 

Specific products include: 
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• A tool for compositional verification that interoperates with Ames’ JavaPathfinder model- 
checker and JavaPathExplorer runtime verification products. 

• A tool that enables interactive definition (through an ADL- architecture description 
language) and visualization of a higher-level architecture. Behaviors of generic components 
can be defined through a specification language or through code fragments. Communication 
primitives between components can similarly be supported either at the implementation level, 
or at a higher level, for early experimentation with partially-specified systems. 

• A tool to support assume-guarantee model-checking at the level of components. This entails 
semi-automatically abstracting interface behavior description from surrounding components. 
For parameterized architectures, this tool will support instantiation and reuse. 

• The identification of architectural properties and features that enable modular, scalable 
verification, which can be used from requirements through system integration. 

MDS (JPL - TRL 6 FY04) 

MDS is a unified flight, ground, and test data system architecture that is based on best practices 
from various disciplines including control systems, robotics, data networking, software 
engineering, and artificial intelligence. Where appropriate it incorporates technologies from 
industry and academia. The design philosophy is based on 13 key themes, each expressing an 
innovative approach to solving specific problems. System state is the architectural centerpiece 
for information processing in MDS. This state-based architecture allows complex system 
behavior to be captured in a simple, straightforward design. There is no other comparable effort 
in the commercial or government sector. 

This component-based design assimilates decades of JPL’s domain knowledge and uniquely 
addresses several space mission needs: 

• Support for planned software reuse 

• Architectural support for autonomy 

• Tailored for the challenging operational and communication constraints that are unique to 
deep space missions 

• Open architecture for the infusion of new software technologies. 

• Promotion of modem software development and management methods. 

MDS objectives are being accomplished in a broadly multidisciplinary manner with flight-like 
discipline to make near-term insertion into flight projects feasible. MDS core products will 
include a unified architectural framework for building end-to-end flight and ground software 
systems. The MDS framework comprises the necessary elements for building goal-oriented, 
autonomous commanding and fault protection; intelligent data management and transport; 
integrated guidance, navigation, and control; and most other capabilities needed for mission 
software. The framework will be pre-integrated and pre-tested. Design patterns and tools for 
adapting the framework for software mission functions will be provided, and customers will also 
receive executable example uses of this framework running a simulated mission. The design is 
object-oriented, and the framework design is expressed in UML. 
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Software Process Products, NASA Organizations, and Institutional Capabilities 

NASA Software Working Group (SWG) 

This inter-Center organization has the charter . .to develop and oversee the formulation and 
implementation of an Agency-wide plan to work toward continuous, sustained software 
engineering process and product improvements in NASA; and to ensure appropriate visibility of 
software issues within the Agency. ...” The SWG provides a forum for inter-Center coordination 
of software process improvement, and works closely with NASA’s Office of Mission and Safety 
Assurance and the Chief Information Officer (CIO). Recently it formulated the software quality 
initiative (under sponsorship of the CIO) that is under consideration for funding as a means of 
improving software process across NASA Centers. 

High-Dependability Computing Consortium and Program (HDCC/P - Ames) 

This effort started its planning phase in FY01 as a joint effort between NASA Ames, CMU, and 
the information technology industry. The high-dependability computing consortium currently 
consists of fifteen Silicon Valley companies that have entered into an MOU between NASA 
Ames and CMU. NASA can no longer afford to develop complex mission software from scratch, 
but components from commercial industry have not historically had the dependability required 
for NASA mission software, nor has their software development process been perceived as 
adequate. This joint effort with the commercial IT industry addresses the problem at its root in 
the anticipated future supply chain for NASA software, where the aerospace contractors become 
system integrators using largely off-the-shelf components from commercial IT industry. 

The main objective of the high-dependability computing program is to provide an empirical basis 
through an experimental testbed facility for validating new processes, methods, and technology 
for software dependability; and then transferring these to industry and NASA enterprises. A 
study on open-source software processes (the ‘Apache’ methodology) began in FY01, 
experimenting with real-time embedded Java software. In FY02 NASA-specific testbeds are 
planned. Interns for these testbed studies will come from commercial IT industry and NASA 
enterprises. 

Develop Software Products (DSP- JPL) 

In response to the NASA directive that each NASA center achieve CMM Level 3 process 
maturity, JPL is initiating the Develop Software Products processes (DSP). The objective of DSP 
is to develop directive and guideline process documentation that aggregates the core ideas in 
existing documentation and organizes it in a manner that makes clear its compliance with the 
CMM. The new organization will clearly differentiate between policy and guideline; make it 
easy for all users to find what they need in order to perform their work; and facilitate evolution 
of the policy and guidelines. JPL’s Center for Space Mission Information and Software Systems 
(CSMISS) is developing a number of best practices and example processes and procedures that 
comply with DSP. 
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Software Inspections and Reading Techniques (JPL and GSFC) 

Reading of products such as code, in conjunction with inspection or walkthrough meetings, is a 
proven verification and validation technique. However, these techniques must be continuously 
assessed and improved. This activity is piloting an integrated, full lifecycle approach to readings 
and inspections, and assessing whether new reading techniques that have been validated under 
laboratory conditions can be applied effectively within NASA. This research builds on existing 
work at JPL and within the SEL at GSFC. 

Component Identification for Safety, Reliability, Maintainability, and Quality Assurance 
(GSFC - Software Assurance Technology Center) 

Early detection of safety critical components is important to allow for additional monitoring and 
testing throughout the lifecycle. Identification of these phrases is currently done by a labor- 
intensive manual search, possibly missing some critical components. This project is developing a 
process that will use key phrases and words in the requirements document to identify potential 
areas of safety critical software. Early identification is essential for cost-effective safety 
measures. 

Principal Components of Orthogonal Object Oriented Metrics and Data Collection for Software 
Quality ( GSFC) 

There is a critical shortage of useable data sets on software quality that are necessary for 
rigorous, statistically-based and meaningful software quality research and subsequent software 
process improvement. NASA projects (specifically development projects) lack criteria that 
specify a minimal set of data to be collected in order to support meaningful research for software 
quality. This effort is improving software reliability though capture and analysis of focused effort 
data as well as increasing software quality by means of expanded defect data and techniques 
such as orthogonal defect analysis and butterfly modeling. Based on independent data sets from 
object-oriented development projects, the mathematical principles of data reduction are applied 
in order to identify intrinsic, orthogonal factors. This will improve reporting by combining 
several metrics into smaller, optimal sets; resulting in reduced effort for data collection, greater 
understanding, and increased metrics usage. 

4.1.3 Scaling Up Software Engineering: Computer-Aided Software Development 

The capabilities, technologies, and products described in this subsection shift the cost, schedule, 
and expected error curves to the right by raising the level at which software is designed, 
developed, and maintained. For example, experiments have shown that programming at the 
specification level rather than the level of conventional programming languages results in a 40:1 
expansion of software (measured by function) that can be done by individual programmers. This 
means not only nearly two orders of magnitude improvement in cost and schedule, but also that 
the non-local interactions are greatly reduced because each individual is able to keep track 
locally of a much larger amount of software. Errors that occur due to miscommunications 
between developers are significantly reduced. Furthermore, the process of detailed 
implementation and optimization tends to spread and diffuse design information throughout the 
code, so specifications themselves are more coherent and localized than code. 
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Due to the mission-critical nature of portions of NASA software, it needs to meet standards 
similar to safety-critical software certification. Traditionally, certification has been done by 
following mandated processes for software development and intensive manual procedures for 
review and testing. These can be costly and introduce schedule delays. Conceptually, automatic 
design synthesis and automatic program synthesis through automated reasoning (described in 
this subsection) is itself a rigorous development process. However, just as in manual 
development, this process needs to be documented and checked through some type of review. A 
technology that can replace some portions of manual review is automated, product-oriented 
certification, in which algorithms process source or object code line-by-line to check compliance 
with safety properties. Traditionally this has been done with low-level properties such as array 
bound checks. Automatic synthesis enables checking higher-level domain properties by 
generating information needed to check these properties as a by-product of the synthesis 
procedure. In this subsection new technology for domain-oriented certification is described. 

4.1.3.1 Computer-Aided Software Development Capabilities 
Design-Level Synthesis and Analysis Capabilities 

Despite the fact that the virtues of carrying out detailed, high-level software design (reduced cost 
and reduced software errors) have been recognized for some time, most software projects within 
NASA do not produce detailed design documents as part of their development. Documentation 
of complex software systems is often incomplete, inconsistent or missing, and abstract designs of 
the systems are non-existent. A likely reason for this is that software designs are difficult and 
time-consuming to produce accurately. However, studies have shown that the existence of 
faithful software designs can significantly reduce both software cost and the risk of software 
hazards. A capability to leverage these advantages is the development of automated tools and 
techniques for aiding NASA software engineers to accurately and efficiently develop models of 
mission software systems. 

A number of high-profile projects within NASA are now following software processes 
associated with modem software design and modeling languages such as UML. These processes, 
in use on the MDS development at JPL and Space Shuttle software at the United Space Alliance, 
advocate an iterative development process whereby requirements, design, and code are 
continuously updated and refined to maintain their consistency. 

Automatic Program Synthesis (APS) Capabilities 

APS is the capability to automatically generate production-quality code from high-level input 
specifications close to domain expert’s formulation of requirements and design. For mission- 
critical code, this is best done through a process of automated reasoning that is analogous to 
humans carrying out a careful, step-by-step development process (i.e., structured programming) 
rather than ad hoc algorithms. For optimal performance, APS is tailored to specific, NASA- 
relevant application domains such as astrodynamics, state estimation, and model-based data 
analysis. The capability of automated reasoning to automatically generate high-quality code also 
includes the following features: 

• Synthesis of extensive documentation and explanations of the code. 
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• Automatic consistency check of code with specification. 

• Check of all assumptions (in specification or implicit) during synthesis. Assumptions used in 
code generation are explicitly called out in documentation, or checked during run-time. 

• APS enables fast exploration of the design space during early stages of the software process, 
thereby not only ensuring that the generated code meets the requirements specification but 
also that the requirements specification and the design are what is intended. 

APS can address several important NASA needs with respect to software development. Software 
related mission failures, like the Mars Climate Orbiter (mismatch of physical units) or the Mars 
Polar Lander (where state estimation software did not properly process and check touch sensor 
data) demonstrate the need for a concise and rigorous software development process and 
technology. APS achieves this through automated reasoning that rigorously implements the 
process of iterative refinement, where a specification is incrementally transformed into code 
using mathematically-justified steps. The capability of APS to automatically ensure consistency 
within the code (e.g., on units, coordinate systems, and frames), and to generate detailed, concise 
documentation with all assumptions called out addresses some of the above issues. APS also 
substantially supports highly iterative lifecycles with fast turnaround times, because production- 
style code can be resynthesized after a change in the specification within a matter of minutes. 
Automatic code generation can provide large leverage factors, especially in application domains 
with high algorithmic complexity, such as state estimation or data analysis. The leverage results 
from three facts: 

• Code generation starts from compact and fully declarative problem descriptions (e.g., 
statistical models) which are much easier and faster to understand, write, change, and 
validate than the corresponding programs. 

• Code generation encapsulates domain knowledge and sophisticated algorithms. It thus 
reduces the level of expertise required to develop programs. This allows scientists to directly 
develop customized production-quality code. 

• Automatically-generated programs are consistent with the underlying problem description. 
This allows a rapid exploration of the design space without the risk of introducing 
programming errors. 

NASA-funded projects have shown that leverage factors of 40: 1 (between C++ code and 
problem specification) can routinely be achieved. 

Capability for Domain-Specific Certification 

The capability to automatically review code for low-level safety properties has existed in 
commercial products for several years. One example is checking for memory leaks (e.g., Purify), 
other examples include low-level resource properties (adequate memory, stack, speed), and 
safety properties about memory and numerical operations. Memory properties include checks for 
out-of-bounds array accesses and dereferences of pointers to deallocated storage; numerical 
properties include overflow, divide-by-zero, and square roots of negative numbers. These code 
review algorithms are typically based on static analysis, which generally scales well and can find 
many types of software errors 
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NASA has many applications where software for specific domains is developed, such as 
precision entry, descent, and landing deep space communication, and deep space navigation. 
Domain-specific certification technology provides the capability of automatically reviewing code 
for compliance with higher-level, domain-oriented properties. Examples of these properties 
include consistent use of coordinate systems and coordinate frames; consistent manipulation of 
numeric variables representing physical quantities with defined dimensions and units; numeric 
stability; and various types of pre/post conditions checks at specified locations in code. Some 
properties are difficult to check without annotations, such as invariants, on the program code. If 
the program is generated by a synthesis system, the synthesizer can often supply these 
annotations; thus, there is synergy between software synthesis and certification. Furthermore, 
the synthesizer can generate a proof that the generated code meets certain properties; the proof is 
then checked by the code review system, which we call the certification engine. This greatly 
extends the types of properties that can be automatically reviewed. 

Technology for Design-Level Synthesis 

Automated reasoning can provide tools to support an iterative development process whereby 
requirements, design and code are continuously updated and refined to maintain their 
consistency. This process, when done manually, requires a great deal of effort from the project 
team and is error-prone. When software development schedules inevitably get compressed due to 
hard deadlines, the effort is typically abandoned. 

Automated reasoning tools can synthesize software design models automatically from 
requirements, and provide automated checking of requirements throughout design/code 
iterations. UML is a typical target for this technology because of its widespread use within 
NASA, but the technology is applicable to modeling languages in general. 

Technology for Automatic Program Synthesis 

Tools for modeling and simulation (e.g., MatLab and Simulink) are used in many projects during 
the early stages of development. Development environments (like MatrixX or ControlShell) are 
supposed to cover the entire development cycle from modeling through design to automatic 
generation of code. These systems seem to be very convenient for supporting the rapid 
development of early prototypes. However, these tools have some shortcomings (especially with 
respect to automatic code generation) that can be addressed by automatic program synthesis 
based on automated reasoning. A typical shortcoming is that the levels of specification and 
generated code are relatively close. This means that the leverage factor is relatively low in the 
sense that many details have to be present in the specification. Furthermore, problems turn up 
when the generated code needs to be integrated with other software. Because these code 
generation tools do not generate justified, well-documented code (with meaningful comments 
going beyond boiler-plate text), manual adaptation and safe integration is difficult. Also, no 
information is present to trace between specification and code, which is an important prerequisite 
for code review and certification. This leads to a pattern, often encountered in practice: the tools 
are used for early stages and prototypes. However, for the production versions, code must be 
manually written, and maintenance and adaptation of the code must be done manually. 
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Deductive program synthesis is an automated reasoning technology for formally generating 
programs from high-level specifications of the program’s behavior. It has been demonstrated that 
deductive synthesis technology can be used to successfully generate high-quality code for 
restricted domains. For each domain, a specification language describes the key concepts in that 
domain (e.g., sensor characteristics, distributions and their associated means/variances) and the 
relationships between them. The specifications form an abstract mathematical model. Each 
domain also contains an underlying domain theory consisting of axioms that specify key 
properties of the domain (e.g., matrix multiplication is associative, a matrix equation can be 
linearized for small perturbations using a truncated Taylor series). Deductive synthesis 
combines the axioms from the domain theory with the specification to generate implementation 
code. This process is formally grounded in logic and hence the generated code can be formally 
traced back to the specification by retracing the logical inferences that were applied. In essence, 
the domain theory formalizes how programs should be built up in the particular domain. The 
domain theory explicitly calls out domain assumptions that otherwise might be left implicit in 
handwritten code. The synthesis process also has the ability to generate alternative 
implementations depending on whether certain assumptions can be shown to be satisfied. 
Additional support for machine-supported certification and V&V is automatically provided by 
the synthesis system in the form of annotations for proof-carrying code, or the generation of test- 
data. Because of the power of automated deduction, the gap from specification to generated code 
that is bridged by the synthesis system can be much larger than that found in traditional 
development tools. This means that the specification can be written in a much higher, more 
abstract and more problem-oriented way. 

Technology for Domain-Specific Certification 

Technology for automatic code review and certification is usually based on some type of 
automated theorem-proving or proof-checking. For simple types of properties the logic of the 
analysis is comparatively simple, and weak forms of checking are adequate. Static analysis refers 
to a broad class of algorithms including techniques used in compilers, where the analysis is done 
with logics for simple mathematical domains such as lattices. Within static analysis, type 
inference is a well-researched family of algorithms with attractive computational properties. The 
complexity of automatic code review depends on the property being checked. In the extreme 
case, some properties of a program are impossible to check algorithmically - for example, the 
termination of a program is undecidable. However, the complexity of automatic review can be 
considerably reduced if additional information is supplied to the checking algorithm. 

The technology of proof-carrying code has a number of components in its architecture. The basic 
idea is that along with source or object code, a complete proof of desired properties is provided. 
The proof is then checked against the code in a separate step by a comparatively simple and 
trusted proof-checking algorithm. This checking can be done at a later time, for example, when 
mobile code is loaded into the execution environment - so even if the code is tampered with, or 
the execution environment does not comply with the assumptions under which the code was 
generated, the checker can detect the inconsistency. For checking object code, we also need an 
annotating compiler, that is, a compiler that produces proof-like annotations into generated 
object code. 
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For domain-specific certification, it is helpful to have the flexibility to easily use different logics. 
Rewriting logic is a universal logic, in the sense that other logics can be easily implemented in it, 
both syntactically and semantically. Membership equational logic additionally provides support 
for types and type inference, a crucial technical aspect for certification. 

4. 1.3.2 Products for Computer-Aided Software Development 
Products for Design-Level Synthesis 

UML Synthesis Tool (Ames) 

This system automatically synthesizes software designs from requirements documents. 
Specifically, the underlying algorithms generate highly structured statechart models from 
requirements expressed as behavioral scenarios annotated with additional constraints expressed 
in a simple logical language. The system maintains the consistency of software models with 
their associated code as the code undergoes maintenance or extensions. Extensions are under 
development for checking automatically if two versions of a software class hierarchy are 
structurally equivalent. In addition, the infrastructure for reverse engineering statechart models 
from existing legacy code using related algorithms is being developed. 

Requirements UML Tool (RUT) (GSFC) 

A set of procedures for capturing and managing system requirements that incorporates UML use 
cases. The tool under development analyzes UML use cases and can assess the quality of 
individual use cases, detect sources of software risks, produce software metrics, and identify 
areas in use cases that can be improved. 

Products for Program Synthesis 

Amphion-NAV (Ames - TRL 4 FY01 ) 

GN&C is a critical software-enabled capability for OSS. Costly mission failures (Ariane 501, 
MCO, MPL) often originate in errors in the state-estimation component of GN&C. Better 
methods for generating reliable state -estimation software are needed. Amphion-NAV 
automatically generates geometric state estimation code used on aerospace vehicles, and also 
produces extensive documentation linking the code to the design-level specification. It has been 
successfully demonstrated generating a suite of graduate-level examples such as Kalman-filter 
software for INS-GPS systems. It is currently being scaled up to generate real-world NASA 
examples such as Mars precision EDL software and rover navigation software. It is targeted to 
support GN&C engineers by enabling them to rapidly explore the design space (including 
accuracy versus computational performance) of state estimation software, and producing 
production-level code. 

AutoBayes (Ames - TRL 4 FY01) 

AutoBayes automatically generates customized data-analysis programs from statistical models 
formulated as annotated Bayesian nets. AutoBayes follows the schema-based deductive approach 
to synthesis, i.e., programs are generated by exhaustive, layered application of schemas. 
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AutoBayes’ schema library comprises schemas corresponding to generic versions of well-known 
statistical and numerical algorithms, e.g, expectation-maximization and Newton-Raphson; the 
schema formalization of these algorithms increases the flexibility compared to a standard 
component-oriented formulation. AutoBayes has already been applied successfully to a large 
number of benchmark problems, including model-based clustering and changepoint detection. 
Case studies have been done on OSS data such as gamma-ray burst data. 

Automatic Code Generation for Concurrent Systems ( GSFC-SEL) 

Algorithms for automatic generation of code for highly concurrent systems have been developed, 
related to agent software. These algorithms accept high-level English-language descriptions, 
convert them to a formal specification, and from that generate efficient implementations in a 
practical programming language. 

Products for Domain-Specific Certification 

Commercial products for automated code review of low-level properties include PolySpace, 
which checks for seven types of potential run-time errors using a sophisticated static analysis 
engine and Purify - best know for flagging potential memory leaks. Compaq has developed the 
extended static checker, which uses a small number of user-supplied annotations to check for 
properties in Java programs. 

Certifiably Correct Code (Ames - TRL 3 FY01) 

This product is synergistic with the automatic program synthesis products developed at NASA 
Ames. The synthesis systems generate annotated code that is then checked separately by the 
certification checker for compliance with domain-oriented properties. A prototype system that 
checks code for compliance with safe geometric calculations (e.g., coordinate frame consistency) 
has been demonstrated built on top of Maude (from SRI). Maude is a system that implements 
both rewriting logic and membership equational logic efficiently, being able to do up to 3 million 
inferences per second on standard PC platforms. Since the complexity of domain-specific 
certification for many properties grows linearly with the size of the program, this provides a 
scalable technology for domain-specific certification. 

4.1.4 Verification and Validation 

Verification and validation are methods and technologies for detecting software errors prior to 
operational use. These methods can be deployed in all phases of software development, for 
requirements definition through testing and maintenance. Design/code review and testing have 
historically been the principle methods for V&V but, by themselves, won’t be adequate for more 
complex future software whose combinatorial explosion of potential execution paths exceeds the 
capability of unaided human reviewers or of testing facilities. This subsection describes 
automation technology for V&V focusing on two principle capabilities needed by NASA: 

(1) behavioral verification, which systematically checks the behavior of a complex software 
system for compliance with required properties, and (2) autonomy software verification. 
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4.1.4.1 Verification Capabilities 
Behavioral Verification Capabilities 

Software that doesn’t branch or contain non-determinism is relatively easy to test, as there are a 
limited number of execution paths. This type of software is epitomized by time-stamped 
unconditional sequences. As the branching structure of a program increases, and it reacts to the 
external environment or to other threads, the combinatorics of the number of possible executions 
becomes prohibitive to test exhaustively. Many of the future IT technologies being developed by 
NASA are characterized by software with high levels of branching, high degrees of reaction to 
non-deterministic environments, and multi-threaded execution. There is a progression from time- 
stamped sequences, to conditional sequences, to rule-based autonomy, agents, and model-based 
autonomy. Testing can cover only very small portions of the number of possible executions as 
we move forward in the future in this progression. 

Technology is needed that is capable of verifying the behavior of complex software, augmenting 
traditional methods of testing and software inspection. Specifically, we need to verify that a 
software system conforms to properties that ensure safe and correct operation - such as the lack 
of deadlock or race conditions (which occurred on Magellan and MPF), conformance to 
invariants and flight rules formulated as temporal constraints. This subsection focuses on 
behavioral verification of complex software in general, while subsequent sections focus 
specifically on autonomy and agent software. Capabilities of behavioral verification include the 
following: 

• Checking of reactive multi -threaded software for conformance to specified properties. 

• Checking of assertions, deadlocks, invariants and temporal properties 

• Generation of error traces that exemplify a software error when the software doesn’t conform 
to specifications. 

• ‘Push button’ automatic verification technology. 

• Analysis of human-machine systems, where the human is modeled as a software agent in a 
highly-interactive loop with a software system. 

Autonomy Verification Capabilities 
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Autonomous system software operates with infrequent and severely-limited human intervention 
to control complex, real-time, and mission-critical processes over periods of months or years in 
poorly-understood environments. Autonomous control systems are being designed that have a 
wide range of behaviors in order to respond flexibly to situations and environments whose 
attributes cannot be completely predetermined in advance. In contrast to previous space systems 
where the onboard controller ran open loop, with the feedback loop completed on the ground, in 
autonomous control systems the feedback loop is completed onboard. An analogy can be made 
with lower-level control functions such as attitude control that are already managed onboard. 
However, the verification methods that are appropriate for quasi-linear and continuous control 
problems such as attitude control are not applicable to the discrete and discontinuous control 
functions addressed by the next generation of autonomy software. 
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The flexibility and power of autonomous controllers requires a departure from standard software 
V&V techniques. Because autonomous controllers adjust continuously to their changing and 
unpredictable environment, they cover a far greater spectrum of situations than traditional 
controllers do. This provides more capability — particularly for long-lived systems operating over 
extended timeframes autonomously — but also dramatically increases the size of the verification 
task. Autonomous systems also feature more advanced software artifacts, with multiple 
interacting components some of which are based on artificial intelligence. This increased size 
and complexity makes traditional V&V approaches based on testing very costly and inefficient. 
Improved V&V technology is a critical prerequisite to ensure that those controllers are reliable. 

4.1.4.2 Verification Technologies 
Behavioral Verification Technology 

The technology for behavioral verification of digital hardware has already been developed and 
provides a base for the scaling of this technology to behavioral verification of complex software. 
The use of this technology by digital hardware designers has become widespread after the Intel 
Pentium floating-point error in 1994- an error in the floating point subsystem of the Pentium 
chip that went undetected even after massive amounts of testing. This error ultimately cost half a 
billion dollars, and spurred the adoption of techniques for mathematically-based verification of 
digital hardware to augment testing and simulation. The mathematical basis for this technology is 
based on automata theory and symbolic logic. Because software has a much larger state space 
than digital hardware (roughly speaking, the difference is the state space of subsystems of a 
microprocessor versus the state space of a microprocessor with a full complement of software 
loaded into ROM and RAM), no one technique is sufficient by itself. To scale up to behavioral 
verification of software, the following technologies must be used together synergistically. 

Model Checking 

Model-checking is a general-purpose verification technique for analyzing models of reactive 
systems, and is especially powerful for analyzing distributed or multi-threaded systems. Explicit- 
state model checking involves generating an explicit representation of the state space of a 
system. Model-checking technology is being developed for application to modem object- 
oriented programs. Rather than drive individual executions of a program, as in testing, model 
checking verifies properties by searching through the state space of possible program executions. 
Under active investigation are all aspects of model checking algorithms including memory and 
speed optimizations, novel search heuristics, as well as parallel and distributed model-checking 
algorithms. While model checking in itself is a fully automatic operation, the task of turning a 
system into a model suitable for model checking can be labor-intensive and error-prone. To 
allow the widespread use of model-checking techniques by the system developers who need 
them, this task must be automated as much as possible, ideally creating the illusion that the 
verification applies directly to the original system. To achieve that, the model checker must be 
able to handle the source representation of the system, possibly through an automated translation. 
Furthermore, any abstraction techniques needed to scale the system down to a tractable 
complexity should be likewise automated. 
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Program Abstraction 

Program-abstraction technology supports the simplification and reduction of programs to enable 
more focused and tractable verification. The technology is based on the theoretical framework 
of abstract interpretation, which provides strong guarantees about the relationship between 
verification results on abstracted programs and the behavior of the real programs. Technology 
development is focused on techniques for abstracting object-oriented programs. 

Static Program Analysis 

Static program analysis technology consists of several classes of algorithms that construct and 
analyze graphs that represent static dependencies within programs. Applications of this 
technology are in program slicing, control flow analysis, concurrency analysis, points-to and 
alias analysis. Static analysis information can be useful in optimizing and refining model- 
checking and program-abstraction techniques. 

Environment Modeling and Generation 

One of the steps in behavioral verification is constructing a model of the environment to which 
the software reacts. Model checking applies to a closed system. In order to check a reactive 
system such as an autonomous controller, that system must be completed with a simulated 
environment with which it will interact — in much the same way as testing requires a test 
harness. The environment must reproduce the different possible stimuli that the system will 
possibly meet when in operation, as alternative choices that the model checker can explore. 
Technology is being developed to support modeling of complex non-deterministic environments. 
Environment models are constructed using a combination of special object-oriented methods to 
support non-deterministic choice, generic reusable environment components and environmental 
constraints specified in linear temporal logic. 

Human/Computer System Analysis 

Human/machine interactions are a common source of critical software-related errors. The 
technology for environment modeling can be extended for modeling the incorporation of human 
actors into system models containing actual software. This technology consists of specialized 
static analysis and program abstraction techniques. 

Autonomy Verification Technology 

Autonomy verification technologies need to address the combinatorial explosion inherent in the 
wide spectrum of potential behaviors of autonomous systems, particularly for model-based 
autonomy. A model used for model-based autonomous control captures all the information 
related to its specific application into a well-scoped, abstract, declarative representation — it is 
the abstract program that is executed, albeit in a convoluted way, by the generic MBR engine. 
This is very different from a controller implemented using a conventional programming 
language, where that information would be scattered through the program code. The availability 
of such a model opens interesting opportunities for formal verification, particularly model 
checking. 
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Symbolic Model Checking of Autonomous Systems 

Past experience has shown that models used in autonomous control are generally well-suited for 
symbolic model-checking techniques (explicit state model-checking technology is described in 
the behavioral verification subsections above). Rather than exploring every single state, symbolic 
model checking manipulates whole sets of states at once, implicitly represented as the logical 
conditions satisfied by those states. These conditions are encoded into data structures called 
Binary Decision Diagrams (BDDs), which provide a compact representation and support very 
efficient manipulations. Symbolic model checking can address much larger systems than explicit 
state model checkers (10 l0 ° states and more), though the size of the generated BDDs can become 
a limiting factor. Though original BDD-based model checking applies to finite, discrete models 
only, extensions have been studied and implemented to analyze timed models and hybrid models 
(mixing discrete and continuous aspects). Symbolic model checking requires a representation of 
the verified system in terms of logical constraints, which is typically easy to extract from the 
declarative models used for autonomous control. 

Exhaustive analysis using symbolic model checking can be used to answer different questions 
about the analyzed model. First, specifications of the controlled system can be formalized and 
checked to verify that the model adequately represents that system. The model can also be 
checked for intrinsic sanity conditions, such as absence of ambiguity or inconsistency. Since the 
model is separate from the MBR engine that peruses it to achieve autonomous control, one 
cannot truly verify on the model alone that proper control will be obtained. Nevertheless, some 
necessary conditions can be usefully checked, for example to show that a path to a given 
operational condition exists from any state. 

Verification through Controlled Execution 

An autonomous controller is a complex program driving a complex system, which can only be 
partially captured by the formal reasoning on the abstract model. Feeding a verified model into a 
sound reasoning engine may fail to achieve the desired control, because of incomplete strategies 
used by the controller in order to improve response time, or because of aspects of the physical 
system not covered in the abstract model. Simulation or testing is still needed. Automated state- 
exploration techniques derived from explicit-state model checking can be used to simulate large 
state spaces in an optimized way and automate the exploration of wide ranges of alternative 
scenarios. Starting from the real controller program, embedded into a software harness that 
simulates its environment, we can instrument both the controller and the harness to allow an 
external verification program to control their execution: select among alternative environment 
responses in the harness, control the order of execution of the different components, save, 
restore, and compare states of the whole system. Given all these capabilities, the verification 
program can apply an explicit-state model-checking algorithm to the real program, backtracking 
between alternative paths and detecting loops, without requiring re-initialization before each new 
sequence. 
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4.1.4.3 Verification Products 
Behavioral Verification Products 

Java PathFinder (Ames - TRL4 FY01 ) 

Java PathFinder is a model checking toolset for Java programs. JPF consists of a model- 
checking engine and a custom Java Virtual Machine that is optimized toward memory efficient 
model checking. JPF also contains static analysis and program abstraction capabilities. 

Generic Verification Engine - C, C++ ( Ames - TRL2 FY01) 

Ames is currently designing new products to support model checking for other programming 
languages. This will be done by providing language-specific front ends and virtual machines 
that interface to the JPF model-checking engine framework. 

Bandera (Kansas State University - TRL4 FY01 ) 

The Bandera program analysis toolset from Kansas State University was developed with 
financial and technical support from NASA Ames. Bandera provides property specification and 
management capabilities, program slicing and abstraction and model-generation capabilities for 
several off-the-shelf model checkers, including Java PathFinder. 

Enhanced Process Algebras (GSFC-SEL) 

The theory of process algebras can be extended with a model of true concurrency. This, together 
with an associated support tool (model checker) could be a significant contributor to mission 
assurance, via improvements to flight software verification & validation. They would improve 
the ability to specify and predict the dynamic behavior of mission-critical software at design 
time, and will thus produce safer, more reliable computer-controlled systems. By detecting 
design flaws early, the approach has the potential to prevent costly redesign or, worse, 
deployment of faulty systems. By separating truly concurrent actions from arbitrary 
interleavings in the model, the technique would allow software engineers to clearly distinguish 
between behaviors that are genuine design features and those that are mere artifacts of their 
model. 

Automated Testing Techniques (GSFC) 

Formal specification techniques have shown themselves to be useful in generating test cases for 
complex systems. Typically, 90% of tests cover less than 5% of the code. Techniques based on 
formal specifications can greatly improve coverage and reduce testing efforts. However, most 
existing techniques do not work well with systems that have great amounts of interaction 
between components and strict timing constraints. This work extends existing techniques and 
devises others that will be applicable to these classes of systems. 
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Autonomy Verification Products 

MPL2SMV (Ames/CMU TRL5 FY01) 

This translator from Livingstone models to SMV converts models used in the Livingstone 
diagnosis system to the syntax used by the SMV symbolic model checker. Specifications to be 
verified are expressed in terms of the Livingstone model and are also translated. Templates for 
common specifications are supported. This tool allows Livingstone users to use SMV without 
being exposed to the syntax of SMV. Experiments with the ISPP controller have demonstrated 
exhaustive analysis of models with 10 55 reachable states. SMV seems to be the obvious tool for 
this problem for a number of reasons. First of all, it is based on so-called synchronous automata 
execution, meaning that all automata execute in a lock-stepped manner (in each transition all 
automata move), whereas this is not the case for most other model checkers. Livingstone models 
exhibit synchronous behavior. Second, SMV’s underlying algorithm is based on BDDs, a 
symbolic technique that has proven to be extremely powerful and superior to other techniques 
falling within the synchronous paradigm. Finally, properties are stated to SMV in CTL, an 
expressive branching time logic allowing many advanced properties to be stated such as safety 
properties and liveness properties. Expressing a property in the CTL temporal logic used by 
SMV is a subtle task, even for V&V experts. To shield the Livingstone programmer from this 
complexity, the translator provides higher-level constructs that refer to Livingstone concepts. 
Such constructs include pre-defined specification patterns for generic classes of properties 
(consistency, state reachability) and auxiliary variables describing the model’s global state 
(number of failed components, number of commands issued). These constructs could be used for 
specifying flight rules in a formal way so that they can be checked automatically. 

Livingstone PathFinder (Ames - TRL2 FY01 ) 

This product is based on closed-loop verification through explicit state model-checking applied 
to the Livingstone diagnosis engine. It uses Livingstone both as the unit under test and as the 
simulator in the testbed. This provides a major increase in accuracy of the verification results, 
since no translation or abstraction of the verified system takes place, as compared to MPL2SMV. 
While analysis of models alone with SMV can identify potential causes of incorrect diagnostics, 
analytic simulation of complete applications actually checks that Livingstone does the right 
thing. On the other hand, real code execution precludes symbolic analysis, so the search space 
has to be narrowed down to a tractable range, typically by focusing on a few typical mission and 
failure scenarios. 

Plan Model Verification (Ames - TRL 2 FY01 ) 

This product encompasses verification technology for model-based planning and scheduling 
systems. The product will ensure that all plans that can possibly be generated for an application 
domain satisfy given conditions, such as safety of the mission system. The principal technology 
is model-checking: the main idea is to transform a planning and scheduling application into a 
formal specification that can be directly used by a model checker to prove properties of the 
application and, in turn, validate the planning and scheduling models. Another technology used 
in the product is automated testing. For the testing part, we automate and expand the analysis 
technique that was performed manually during DS1 RAX. Such analysis is based on identifying 
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parameter-based equivalent classes of intervals and generating test cases for each of the intervals. 
Identifying such equivalent classes of intervals reduces the number of test cases while achieving 
full coverage. For projects involving the development, use or testing of autonomous planning 
and scheduling systems, we expect this product to reduce the time required to build and validate 
the planner by over 50%. 

Plan Checking Through Lightweight Formal Methods (JPL TRL05 FY01) 

Lightweight formal methods are characterized as having an application cost that grows no more 
than linearly with the size of the problem, and that employ automation to relieve the human user 
of some burdensome, tedious, analysis task. The advantages of the automation are that it makes 
for a reliable and repeatable component, as well as the time savings themselves. Lightweight 
formal methods (e.g., automatic generation of test oracles) were initially applied in some pilot 
studies of various simple analysis (internal consistency/completeness) of custom spacecraft 
documentation (design documents, and test logs). Successes here led to the extension of the 
ideas, to double-check the outputs of an AI planner for adherence to flight rules. In testing 
parlance, this became a "test oracle". This work illustrated aspects that are perhaps recurring in 
lightweight formal methods in general: judicious use of automation translation between formal 
notations; building a core analysis capability, then extending it opportunistically; using pilot 
studies to predict cost and feasibility; inventive use of analysis methods - e.g., use of a database 
like capability to serve as analysis reasoning component; partnership between domain expert and 
analysis expert. 

Formal Specification of Agent-Based Systems ( GSFC) 

Quite a number of software applications within NASA now involve the use of intelligent agents. 
Unfortunately, as these systems become more and more complex, the interaction (and, often, 
interference) between different agents is not always clear. While agents often must intentionally 
compete for resources in order to find the best possible solution, sometimes the result is 
undesirable. The problem is exacerbated by the fact that these systems are all but untestable, as a 
system that truly exhibits intelligent behavior is not likely to repeat the same execution pattern 
on a subsequent "run." Along with Code 588, we are looking at ways of developing reliable 
agent-based systems by application of various formal specification techniques. 

4.1.5 Error Recovery 

Runtime error recovery is the last line of defense for reliable software, for errors that escape 
detection during V&V and testing. Space mission vehicles are characterized by tightly-coupled 
systems with complex interactions. This can lead to seemingly minor software faults at runtime, 
such as an overflow in non-critical guidance software for the Ariane 501, cascading into a 
mission failure. A remedy is to provide fault tolerance or fault detection and recovery 
capabilities for the software itself - a capability that has been standard for hardware faults for 
decades. However, there are characteristic differences between hardware and software: for 
example, redundancy is one method for handling hardware faults, but since software faults 
originate as design errors, simple redundancy is ineffective. There are also differences in terms 
of the phase of flight. For faults that occur in the quiescent cruise phase, a minimalist safing 
mode with ground-based bug detection, patching, and reboot has worked historically, though at 


91 



Chapter 4. NASA Information Technology Research and Development 


the cost of increased mission staffing. However, during critical phases of flight, such as during 
the execution of a landing sequence, there is no time for a reboot controlled from ground. 

In this subsection we describe current NASA IT investments in runtime software fault detection, 
but recommend that more investment be made in software error recovery. 

4.1.5.1 Runtime Monitoring 
Runtime Monitoring Capability 

Runtime monitoring compares the runtime execution of a software system against a model of 
correct program behavior. A model of correct behavior can be a high-level requirement 
specification stating temporal relationships over time, such as flight rules for a spacecraft. 

Models can also be software-specific, such as deadlock freedom in concurrent programs. If the 
expected behavior specified in the model is violated, proper action can be taken instead of having 
the error blindly propagate. In some cases, event traces indicative of an impending error can be 
detected and action taken prior to the error occurring. 

Runtime Monitoring Technology 

A technological challenge for run-time monitoring is the trade-off between sophisticated 
monitoring capabilities and the limited computational resources onboard spacecraft. Another 
challenge is to generate instrumentation of the code - the software equivalent of hardware 
sensors. Manual generation of instrumentation is time-consuming and error-prone. The following 
technologies, still under active R&D, are needed for runtime monitoring: 

• Automated code instrumentation from specifications. 

• Interface technology that receives signals from instrumented code and produces the event 
traces needed for monitoring. 

• Efficient monitoring technology that does not interfere with the expected run-time 
performance of the monitored system. 

Runtime Monitoring Product 

PathExplorer (PAX — Ames, TRL 3 FY01) 

PAX consists of three main modules: an instrumentation module, an observer module, and an 
interconnection module that ties them together through the observed event stream. The 
instrumentation module performs a script-driven automated instrumentation of the program (or 
programs) to be observed. The instrumented program, when run, will emit relevant events to the 
inter-connection module, which further transmits them to the observation module. The observer 
may run on a different computer, in which case the events are transmitted over a socket. 

The observer receives the events and dispatches these to a set of observer rules, each rule 
performing a particular analysis that has been defined in the model. Generally, this modular 
rule-based design allows a user to easily define new runtime verification procedures without 
interfering with legacy code. The rules are divided into two kinds: 
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• Specification-based rules. Such rules refer to a high-level requirement specification of what 
the expected program behavior should be. The specification is written in some formal 
language, representing either some form of temporal logic or some form of state-machine 
language such as UML state-charts. The language may have a graphical representation 
making writing such specifications intuitive. Such rules are good for stating domain-specific 
properties about a software system. 

• Algorithm-based rules. Some rules are not easily stated in a formal logic and need 
formalization in a complicated algorithm. Some examples are general rules for detecting 
deadlock and data-race potentials in concurrent programs. In order to find such deadlock 
potentials, one needs to analyze the order in which locks are taken by various threads, and 
this is more easily expressed as an algorithm. 

4.2 Highly-Robust Autonomous Systems 

In order to accomplish the next generation of challenging missions, NASA must develop highly 
autonomous systems capable of making critical decisions independently of human operators, as 
well as mixed-initiative ground-based systems that work in collaboration with humans to support 
missions. Current missions are accomplished using a combination of direct human control and 
preprogrammed “canned” responses. This approach sets a strong boundary on what we may 
accomplish in the future due to communications delays, light speed constraints, mission 
complexity, and cost. Future missions need to operate under circumstances in which direct 
human control is often impossible, impractical, or too expensive. Examples of such missions 
include the robotic colonization of Mars, Sensorweb, a Europa submarine and, ultimately, an 
interstellar probe. Autonomous systems capable of independent decision-making will enable 
these missions by maintaining vehicle health and safety, accomplishing complex science and 
mission goals, and adapting to changing circumstances or opportunities. 

4.2.1 Robust Autonomy Technologies 

Autonomy focuses on techniques that allow a spacecraft or system to react to uncertainties 
within the environment in a robust fashion while attempting to achieve a set of high-level goals 
or objectives. Autonomy can be subdivided into the following broad classes of capabilities: 

• Health management 

• Planning and scheduling 

• Autonomy architectures 

• Collaborative and coordinated decision making 

• Learning and adaptation 

• Intelligent sensing and reflexive behavior 

• Robust execution. 

In all of these areas, systems are being developed both within NASA, and in the larger research 
and industrial communities. NASA’s mission challenges, however, are often quite different from 
those encountered in other contexts. First, NASA requires extremely high levels of autonomy 
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within unknown environments. Second, the devices being developed often cannot be fully tested 
until they are deployed at which point they must already be fully operational. Finally, NASA is 
often developing one-of-a-kind devices that have unique mission goals and objectives. Because 
of these requirements, it is critical to develop techniques that facilitate the rapid development of 
customized autonomy software that leverages the knowledge of the designers and the domain 
experts whenever possible. In addition, the software must be able to adapt to changes within the 
environment and to the performance of individual components. The ability of the system to adapt 
is particularly important for long-duration missions in which component degradation is 
inevitable. 

A number of general technologies for achieving autonomy are described below. These 
technologies provide a framework within which capabilities of autonomy can be realized in 
space systems. 

4.2.2 Health Management 

This technology consists of a process for (1) determining that a system is in a fault or a failure 
state, i.e., a state in which at least one parameter of the system deviates from the acceptable or 
nominal value; (2) the diagnosis process must determine the description of the fault, including its 
type, location, time, and magnitude; and (3) the recovery phase involves recommendations for 
actions that will put the system into a desired state in the face of the fault or failure. 

The autonomy capabilities enabled by health management include: 

• Autonomous mission operations 

— Ensuring smart safe-hold in robots 

— Error detection with few false alarms. 

• Constellation health and safety 

— Fault diagnosis, recovery, and reconfiguration ensuring reliability for long duration 
missions 

Examples of technology products in this area include: 

Livingstone 

Livingstone uses a model of the spacecraft hardware that combines logic with probabilities, and 
searches system-wide interactions to detect and isolate failures, and generate recovery options. 

An earlier version of Livingstone was flown on Deep Space One. The limited computational and 
memory resources available to the experiment have driven the team to implement new 
algorithms that greatly improve Livingstone’s efficiency and size. Livingstone can increase the 
reliability and cost-effectiveness of any mission that uses complex engineered systems such as 
spacecraft or rovers. 

Hybrid Diagnosis 

This project is intended to develop technologies for model-based diagnosis of hybrid systems 
such as planetary rovers. The approach being explored is to build a hybrid model of a system as a 
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set of discrete operational modes, each of which is described by a set of differential equations. 
This model can then be used to predict likely future trajectories for the system given a current 
state, and these trajectories can be compared with actual sensor readings to diagnose what the 
true system state is likely to be. At present we are investigating approaches based on particle 
filtering, but we plan to investigate other techniques as well. The technology is currently TRL 1 
or 2. 

Adaptive Envelopes 

This project develops automated methods for learning upper and lower bounding functions, for 
predicting nominal ranges for each engineering sensor over time. It exploits available historic 
data (e.g. early mission or simulation data), to cheaply learn and adapt predictive models with 
minimal manual effort. Bounding function inputs include other sensors, yielding bounds which 
are very context-sensitive (i.e., compared to traditional red-line limit-sensing). Methods include 
advances in large-scale support vector machines and high-dimensional nearest-neighbor search. 

BEAM/PRISM 

Beacon-based exception analysis for multi-missions (BEAM) is a novel spacecraft-independent, 
event-based, signal monitoring methodology which combines advances in adaptive wavelet 
theory, nonlinear information filtering, neuro-fuzzy system identification and stochastic 
modeling. It is intended for deployment as part of an autonomous self-diagnosis and monitoring 
system onboard any spacecraft. With the exception of neuro-fuzzy diagnostic algorithms, none of 
the other techniques have been previously applied for integrated real-time spacecraft health 
assessment. From an algorithmic standpoint, BEAM provides an extremely formal and robust 
approach to spacecraft analysis at the system level, that goes well beyond traditional red-lining 
and trending filters endemic to telemetry-based monitoring systems. Several by-products have 
also resulted from BEAM development, in the form of new design-for-operability and design- 
for-testability tools. 

Primary research objective is to develop BEAM in the framework of a new fault detection and 
isolation paradigm called an active state model. This model is one which will possess a degree 
of autonomy from the environment that allows it to perform purposeful transitions not directly 
controlled from the outside. It must possess self-identification, self-awareness, and self- 
intelligence capabilities. BEAM will be expanded in the areas of self-identification and self- 
awareness. To accomplish this, software and demonstrations to develop this concept will be 
constructed, adding to the theoretical development completed under the gray box effort in 2000. 

Data Summarization/Beacon Operations Technology 

Automated selection and prioritization of the most useful data, using statistic summaries and 
machine learning techniques to identify interesting events in the data. Interesting events include 
not only "unusual" behavior, but also when behavior becomes more normal again. Includes 
novel methods for low-dimensional visualization of high-dimensional multivariate data. 
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Data Summarization / Beacon Operations Relevance 

Suitable for automated downlink determination under limited bandwidth (e.g., deep space 
missions) or other resource-limited (e.g., time, available crew) situations (e.g., focus of attention 
during time-critical HEDS diagnosis analysis). 

Time-Series Pattern Matching Technology 

A hybrid of novel probabilistic and generative methods for efficiently searching for query 
patterns in large time-series databases. Loosely speaking, the goal is a "Google-like" search 
engine for NASA time-series data sets, exploiting and handling the special nature of such data. 
Proposed methods include support vector machines, high-dimensional kemel-distance indexing 
trees, and novel hidden Markov model methods. 

Time-Series Pattern Matching Relevance 

NASA mission operations generate volumes of engineering data. This historic data can often be 
of great importance, for example, in determining that a situation similar to a current problem 
occurred before (and indexing into associated logs of analysis and corrective actions taken in that 
previous case). Existing search techniques are inadequate for the demands of such data, due to 
the large time scale (e.g., multi-year missions) and high dimensionality (e.g., thousands of 
sensors). 

4.2.3 Planning and Scheduling 

Planning and scheduling research focuses on the process of reasoning about a set of high-level 
goals and objectives and determining a sequence of actions that satisfy these goals. Research 
within this area includes: the generation of plans and schedules that allow flexibility at the time 
of execution; integration of a planning and scheduling system as part of an onboard, closed-loop 
controller; mixed-initiative techniques that allow the system to interact with a user when 
generating the plan; and the ability to scale up existing techniques to larger problem sizes. 

The autonomy capabilities enabled by planning and scheduling technology includes enhanced 
science productivity in spacecraft and rovers 

Examples of technology products in this area include: 

• Conditional execution 

• Resource management 

• EUROPA. 

Operations plans are inherently composed of activities that have been constrained and ordered so 
that their execution results in desired goals being achieved, while applicable constraints, flight 
rules and operation limitations are respected. Constraint-based planning is based on reasoning 
about and generating plans in which both activities and constraints are made explicit. This is 
done by reasoning about parametrized intervals that represent activities on different subsystems, 
with interaction constraints linking intervals and their parameters. 
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The ongoing constraint-based planning effort aims to 1) generalize the approach to handle 
complex real-world constraints, 2) modularize the implementation, and 3) pave the way for a 
more efficient and easier-to-use planning system that can be used directly by mission engineers. 

The final product is an autonomous multi-mission planning and scheduling system that can be 
used to generate and verify plans for a broad range of applications, including on-board and on- 
ground mission operations planning, experiment scheduling, and resource allocation. 

The current version of the system is operational at the level of beta-testing software. All the 
main functionality is in place and has been tested on various problems. The emphasis of ongoing 
work is on improving system performance, further developing a new approach to effectively 
reason about complex resources, and design techniques to avoid the reliance on human- 
developed heuristics to guide the planning effort. 

Distributed Architecture for Science Observation Scheduling for 
Fleets of Earth-Observing Satellites 

NASA will soon deploy fleets of Earth-observing satellites to take high resolution images of the 
Earth. Demand for science observations by Earth scientists will be high, and managing the high- 
resolution observations, as well as the satellite resources required to capture and downlink the 
images to Earth, present a difficult optimization problem. This project is developing 
sophisticated techniques, based on constraint-based planning and stochastic optimization search, 
for managing satellite observation scheduling. 

SOFIA - Mixed Continuous-Discrete Constraint Optimization 

This work is being conducted as part of the SOFIA General Investigator program. In the SOFIA 
domain, decisions must be made about real-valued quantities subject to a wide variety of 
constraints. The ongoing work is crucial to address the mission operations requirements of the 
SOFIA General Investigator program, and the SOFIA flight planning application drives our work 
in this area. 

Limited-Contingency Planning 

Throughout a mission, detailed mission operations plans must be constructed, validated, and 
uplinked to a spacecraft or rover. Currently a mission operations plan takes the form of a rigid, 
time-stamped sequence of low-level commands. Unfortunately, there is uncertainty about many 
aspects of task execution: exactly how long operations will take, how much power will be 
consumed, and how much data storage will be needed. Furthermore, there is uncertainty about 
environmental factors that influence such things as rate of battery charging or which scientific 
tasks are possible. In order to guard against this uncertainty, current plans are based on worst- 
case estimates and contain fail-safe checks. If tasks take less time than expected, the spacecraft 
or rover just waits for the next time-stamped task. If tasks take longer than expected, they may be 
terminated before completion. In fact, all non-essential operations may be halted until a new 
command sequence is received. All of these situations result in unnecessary delays and lost 
science opportunities. This project aims to address this problem by developing automated 
planning technology that can produce contingency plans. A contingency plan contains additional 
branches that provide alternative courses of action when the outcome of previous operations does 
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not meet expectations. These exceptions may be due to operations taking more or less time or 
resources than predicted, unexpected environmental conditions, or outright failures of procedures 
or hardware. In these cases, contingency branches allow a spacecraft or rover to perform 
potentially-useful diagnostic operations, and/or alternative scientific operations. 

Automated Scheduling and Planning Environment (ASPEN) 

ASPEN is a flexible, reusable, application framework for developing automated planning 
systems. ASPEN automatically generates plans of activities to achieve desired goals while 
respecting operations constraints involving states, resources, and timing. ASPEN has been 
applied to ground-based and onboard planning problems such as: antenna ground station 
automation, autonomous spacecraft, rovers, and unpiloted aerial vehicles. 

Continuous Activity Scheduling Planning Execution and Replanning ( CASPER) 

An autonomous spacecraft must be able to plan ahead to avoid shortsighted decisions that can 
lead to failure, yet it must also respond in a timely fashion to dynamic and unpredictable 
environments. CASPER uses iterative repair to support continuous modification and updating of 
a current working plan in light of changing operating context. This continuous planning 
approach enables CASPER to respond to anomalies or opportunities in a rapid timescale (tens of 
seconds on a flight processor). 

Distributed Planning and Execution 

Over the next 10 years NASA plans to fly ever-increasing numbers of probes to observe both the 
Earth and Mars with sensors that have overlapping functionalities. Managing these overlaps 
among multiple autonomous spacecraft involves assigning observation goals to spacecraft and 
continually reassigning goals as anomalies and new observation opportunities arise. In order to 
facilitate this form of loose coordination, this research focuses on goal migration using continual 
goal-distribution planning and the interface between continual planners and contract networks. 

In order to facilitate this form of goal migration we are developing two complementary 
techniques. Goal distribution planning will let a designated lead spacecraft/rover plan with an 
abstract model of all followers in order to assign goals across the population. Contract networks 
will let any spacecraft/rover serve as an auctioneer to distribute goals. These two approaches are 
actually two points in a spectrum of approaches where the leader gives its followers 
progressively more autonomy in deciding who satisfies which goals and how to satisfy a goal. In 
addition to extending these approaches to work with continual planners, this research explores 
the spectrum by developing a hybrid system that uses both approaches. 

Adaptive Problem Solving 

Proposed missions to explore comets and moons will encounter environments that are hostile and 
unpredictable. Any successful explorer must be able to adapt to a wide range of possible 
operating conditions in order to survive. The traditional approach of constructing special- 
purpose control methods requires information about the environment, which is not available a 
priori for these missions. Adaptive planning uses a flexible problem-solver with significant 
capability to adapt its behavior. Using adaptive problem solving, a spacecraft uses reinforcement 
learning to learn an environment-specific search method. Adaptive planning algorithms use 
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reinforcement learning to evaluate a set of control strategies so that they can be ranked in terms 
of their utility for problem instances. A search method will generate new control strategies based 
on the highest scoring control strategies of the previous cycle. The cycle then repeats with this 
new algorithm. 

Portfolio Planning Algorithms 

Algorithm portfolios are sets of algorithms designed to work synergistically to solve a problem. 
In a synergistic portfolio the whole is greater than the sum of its parts: the probability of at least 
one algorithm succeeding is greater than the sum of the independent success probabilities, due to 
negative correlations. Algorithms can be combined within a single run to enable multiple 
algorithms to solve a single problem instance (approaching multi-strategy cooperative problem- 
solving). Portfolios containing stochastic algorithms can exploit rapid restarts, which is 
beneficial for certain problem classes. This research investigates the use of stochastic 
combinations of search heuristics in the ASPEN planner using the iterative repair framework to 
improve local search on a wide range of problem domains. 

Combinatorial Optimizers for Use with Planning 

Automated mission planning systems have already demonstrated the ability to reduce mission 
planning effort, improve mission quality, and reduce operations costs. There are a number of 
important NASA planning problems, however, for which current general-purpose planning 
systems cannot produce high quality solutions to large real-world sized problems within 
reasonable time bounds. Many of these problems contain combinatorial optimization sub- 
problems that interact with the overall planning problem. This work provides the capability for 
significantly improving planner performance by integrating specialized solvers into general 
purpose planning systems. It will enable general-purpose planners, which are at the core of 
autonomy, to solve these difficult classes of planning problems better and faster than they can 
now, and in many cases enable them to solve problems that are currently intractable. It will also 
provide optimization algorithms for two planning problems, observation scheduling and swath 
selection, that are critical to sky survey and planetary mapping missions. 

4.2.4 Autonomy Architectures 

Autonomous systems seek to achieve high-level goals and to react in real time to their 
environment. Architectures for autonomy differ in their approaches to achieving these objectives, 
and can be classified into three types: behavioral, hierarchical, and hybrid. Behavioral 
architectures use a bottom up approach, whereby groups of concurrently operating software 
modules called behaviors are grouped together, and interact through communication and 
interacting with their environment. By contrast, hierarchical architectures use a top-down 
approach, achieving autonomy objectives by decomposing high-level, abstract goals into 
successively more concrete and detailed sub-goals. Finally, hybrid architectures combine top- 
down and bottom-up approaches. 

The autonomy capabilities enabled by architecture technology includes: 

• Intelligent System Control and Navigation. An intelligent controller is responsible for 
executing a sequence of commands in a robust fashion while monitoring and responding to 
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failures within the system. Given some specification of the sequence of tasks to be 
performed, an executive is responsible for reactively selecting the next action to be taken 
based upon the sensory inputs available at that time. The key challenge to be addressed is the 
development of techniques that provide guaranteed real-time response given a flexible 
sequence of tasks while still reasoning about the myriad of system-wide interactions and the 
future ramifications of an action. 

Examples of technology products in this area: 

• IDEA - unified planning and control for distributed agents 

• Coordination protocols for distributed spacecraft 

• MDS - unified flight architecture including autonomy support (scheduling, goal based 
commanding) 

• CLARAty - 3-tiered architecture for rovers. 

4.2.4.1 Collaborative and Coordinated Decision-Making 

This technology addresses the need for cooperation between independent autonomous agents 
when they must collaborate to achieve a common goal. Effective cooperation requires resources 
to be shared across systems and the assignment of roles and responsibilities to minimize the 
coupling between agents while still ensuring coordination in the attempt to satisfy the higher- 
level mission goals. Distributed decision making is critical for missions such as a robotic colony 
on Mars, deployment of a fleet of sensing devices orbiting Earth, or within an armada of 
cooperating deep space probes. In addition to these different levels of control, a variety of other 
critical issues must be addressed. Of critical importance is the ability of the autonomy software 
to interact seamlessly with the humans who will be interacting with the system. In the end, few if 
any missions will be fully autonomous. Invariably, humans will be interacting with the 
autonomous system at some level. Autonomy techniques must facilitate this interaction and 
ensure varying levels of autonomy depending upon the mission phase and the needs of the 
humans with which the system is interacting. 

The autonomy capabilities enabled by collaborative/coordinated decision-making technology 
include: 

• High Precision Formation Flying. Future missions will require advanced technologies for 
autonomous maintenance of satellite constellation formation. Satellites in formation will 
perform coordinated movements, communication, and scientific observations. Sometimes, as 
with ST 5, they will be required to behave as a single unit to maintain communication with 
the ground. 

• Fault Tolerant Distributed Robotics. This capability will enable tightly coordinated colonies 
of small, relatively simple robots to perform tasks in hostile environments. Fault tolerance 
will be achieved through redundancy. To be effective, such a system must be homogeneous 
and scalable, and individual elements must coordinate using cooperative or competitive 
strategies. 

Examples of technology products in this area: 
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• Coordination protocols for distributed spacecraft 

• Distributed planning and execution 

• Collective intelligence. 

Many information technology tasks cannot be effectively addressed in a centralized fashion. 

Such tasks can only be achieved by casting the system as a distributed collective of self- 
motivated adaptive agents. Examples of such tasks include coordination of multiple spacecraft, 
routing across a telecommunication network, data migration/job scheduling in a distributed 
computer, and control of a swarm of nanobots. With such collectives we are confronted with an 
inverse problem: How should we initialize/update the agents’ goals to ensure that as the system 
unfolds, the agents do not work at cross-purposes, and their collective behavior achieves the 
provided global goal? 

The science and technology needed to solve this problem is known as collective intelligence. 
Drawing on ideas from machine learning, economics, game theory, and physics, it has achieved 
major improvements over conventional techniques in many different application domains. 
Examples include control of dynamic migration and scheduling of both jobs and data across a 
heterogeneous computer system, and control of a constellation of telecommunication satellites so 
as to maximize the scientific value of data successfully downloaded to Earth. 

4.2.5 Learning and Adaptation 

Machine learning focuses on developing data-driven techniques that can assist engineers and 
scientists in the decision making process and suggest actions that lead to a desired outcome. The 
results developed are applicable when monitoring, controlling, and maintaining complex devices 
as well as when analyzing scientific data to make decisions. One issue to be addressed is the 
transition from just predicting the value of a feature to selection of an action that optimally 
achieves a desired outcome in the world. This task requires the ability to develop predictive 
models and autonomously learn their behavior in order to determine how alternative actions will 
perturb the system. In the Earth sciences, climate models can develop localized instabilities 
which can be resolved if meteorologists (or in the future a space sensor web) collect additional 
observations about the atmosphere to feed into the model and reduce forecast uncertainty. 
Understanding when complex systems change and what actions can alleviate predictable risks or 
uncertainties is major challenge of machine learning. 

The autonomy capabilities enabled by learning and adaptation technology include improved 
spacecraft fault tolerance. 

Examples of technology products in this area include: 

• Evolvable hardware is a new biologically-inspired computer search technology that borrows 
the fundamental Darwinian process to automatically design, optimize, reconfigure, and 
increase fault tolerance of engineered structures. Evolutionary algorithms form the 
foundation of evolvable hardware technology. Applications in the field include jet engine 
and airfoil optimization, electronic chip, and bridge truss design. 
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Our group’s products are the underlying computer algorithms for evolvable hardware. We 
are focused on producing coevolutionary genetic algorithms for applications in fault 
tolerance for reconfigurable chips, circuit and antenna design, and robotic control. In 
addition, our algorithms have wide applicability in multiobjective optimization problems 
such as scheduling, costing, payload design, and human factors. Our products — evolutionary 
algorithms and the resulting hardware artifacts — are mainly in the proof-of-concept stage. 
Thus the technology is currently between TRL 2-3. Conservatively, we estimate it will be 
4-6 years until mission insertion. 

Our products that improve fault-tolerance can enhance any mission containing reconfigurable 
electronics. Autonomous, self-repairing electronic systems will be possible with the advent 
of fast genetic coprocessing chips. These chips would monitor the health of the spacecraft’s 
systems, detect faults, and use an evolutionary algorithm to evolve a repair solution on the 
fly. 

• 3D Super-Resolution. This project is aimed at combining multiple images of a region of 
interest (on a scale from individual rocks, to whole bodies such as asteroids) to reconstruct a 
single surface model that is at much higher resolution than any one of the images. That is, by 
3D super-resolution, we mean that when the reconstructed surface is projected into any of the 
images, the surface elements project into an area much smaller than an individual pixel. This 
project has been demonstrated on synthetic images of a region, where low-resolution images 
generated from a surface are combined into a single, high-resolution surface estimate. 

Current work is to demonstrate the system on selected NASA mission data. This project is a 
science enabler, as it allows the maximum extraction of useful scientific information from the 
images collected by a camera. The increase in resolution of the 3D model from combining 
the information enables small features on the object that are not apparent from the individual 
images to be determined. This is a follow-up project to the 2D super resolution project that 
was successfully used as part of the Mars Pathfinder mission. 

• 3D Surface Reconstruction via Bayesian Inference. This project is building an inference 
system for reconstructing the geometry and reflectance properties of a surface from images 
of the surface. The methodology is based on a model-based Bayesian statistical approach, 
where we directly uncover the parameters of a surface model. There is in principle no 
limitation on the types of object or types of reflectance properties that can be reconstructed 
(though in practice the system as currently implemented has restrictions on the topology of 
the objects and the types of imagery that can be used). The system can be used with orbital, 
descent and/or rover imagery, building up an increasingly detailed model as the resolution of 
the imagery permits. We have demonstrated a system that takes simulated satellite images of 
a region and reconstructs a dense surface model from these images. Currently we are 
working to demonstrate the system on real images and other NASA mission data. This 
project is enabling for many Code S missions. For example, it can be used to build surface 
models from orbit to choose safe and scientifically interesting landing sites. It can also be 
used to refine the surface model during the descent phase, and can be used as an enabler for 
rover autonomy. It also provides a single surface model that integrates the scientific 
information (morphology and reflectance) and is also useful for navigation and engineering 
uses. By building an onboard model of the surface, it also enables more detailed onboard 
science, reducing the required transmission bandwidth by enabling selective transmission. 
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4.2.6 Robust Execution 

A complete list of autonomy products/systems follows: 

• Evolvable hardware 

• Conditional execution 

• Resource management 

• Photorealistic virtual reality 

• Reinforcement learning for robot execution 

• Rover target tracking 

• X34 - ground/flight architecture for model-based diagnosis 

• EUROPA 

• Model specification, analysis and validation 

• Ground/flight distributed architecture for science observation scheduling 

• SOFIA - mixed continues-discrete constraint optimization 

• IMAGEbot - planning technology for management of large science data repositories 

• Limited-contingency planning 

• MER prototype of resource planning for science 

• Contour - knowledge capture for long duration missions 

• IDEA - unified planning and control for distributed agents 

• Coordination protocols for distributed spacecraft 

• MDS - unified flight architecture including autonomy support (scheduling, goal based 
commanding) 

• ASPEN - batch/human interactive planning and scheduling system 

• CASPER - onboard planning and scheduling system 

• CLARAty - 3-tiered architecture for rovers 

• Planning for mission design 

• Adaptive problem solving 

• MISUS - multirover novel/interesting science recognition, subgoaling, planning, execution, 
and evaluation 

• Combinatorial optimizers for use with planning 

• Portfolio planning algorithms 

• Integrated planning and execution 

• Distributed planning and execution 

• Autonomous retargeting and downlink selection 
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• Hypothesis-driven onboard science 

• StarTool - solar feature recognition and tracking 

• SkiCat - clustering and cataloging of astronomical sky surveys 

• DiamondEye - data mining and discovery 

• Temporal and spectral data mining/super-resolution 

• Machine vision for safe and precise landing 

• Adaptive envelopes. 

4.3 Computing, Communications, and Distributed Computing 

This section describes the infrastructure services underlying the IT services described in other 
sections. The topics covered are computing and communication, and each is divided into on- 
board and ground. The tasks in each area are grouped into technology development or products. 

4.3.1 Computing 

4.3.1.1 Onboard Computing: Hardware 
Capabilities 

Future missions will require more onboard computing capacity both to accommodate the 
increased demands of onboard control algorithms (such as NGST, SIM, TPF, MMS, MEP) and 
the increased data processing needs (such as TPF, GLAST, OWL, CNSR, and SRO). In addition 
some missions have modest onboard computing requirements but very stringent power 
constraints (such as SRE, Neptune Orbiter, and MagCon). The commercial marketplace is also 
being driven to produce devices with high performance and low power consumption, but these 
developments are focused mainly on consumer devices which have no requirement for radiation 
hardness. This section focuses on research and development efforts to produce more capable 
processors which can operate in a harsh space environment. Figure 4-3 shows radiation- 
hardened microcomputers lagging commercial microcomputers by at least two orders of 
magnitude in performance. 

Technologies 

There are several possible approaches to solving the problem of providing substantial computing 
capacity with low power consumption. In the Tong term, quantum computing offers order of 
magnitude increases over conventional computers by reducing the number of charge carriers 
required to represent a bit of information. In the intermediate term, adaptive computing 
techniques reconfigure hardware for specific algorithms in order to achieve greater performance 
than general-purpose parts. The challenge for adaptive computing is not only to produce 
radiation-hardened components but also to provide the software tools to make this flexibility 
available to the end user. In the near term, missions will be able to take advantage of enhanced 
radiation-hardened processors and special-purpose processors in the next few years. 
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Figure 4-3. Space Flight Avionics and Microcomputer Processor Trends 


Products 

Miniaturized Semiconductor Electronic and Optoelectronic Devices (ARC). 

ARC has long term research projects underway to develop theory and modeling tools to analyze 
and design future generations of miniaturized semiconductor electronic and optoelectronic 
devices and study the effects of harsh space environments on these devices. Anticipating limits 
of the application of miniaturization in space and terrestrial computation, research is also 
underway to explore alternate technology for computation and sensing based on nanoscale and 
molecular systems combined with new models of computation inspired by quantum physics and 
biology. This research is carried out in conjunction with experimental research projects and 
revolutionary computing algorithms research projects. 

POC: T.R. Govindan 

TRL 2-4/2002 

Quantum Computing (JPL) 

The objectives of the quantum computing project are to develop novel quantum algorithms and 
designs for quantum devices that tackle computational and sensor problems of practical 
significance to NASA. A quantum computer is a computing device that can harness delicate 
quantum effects to achieve unparalleled computational abilities (such as breaking secret 
cryptosystems, solving decision problems, searching virtual databases, and simulating physics). 
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These quantum effects include superposition, entanglement, interference, non-determinism, non- 
clonability and non-locality. 

POC: Benny Toomarian 

TRL 6/2010 

Adaptive Computing (GSFC) 

The objective of the adaptive computing task is to formulate a road map to the utilization of 
reconfigurable systems for Earth science applications. Specific objectives include: (1) evaluate 
current state-of-the-art reconfigurable computing technologies for hardware and toolkit I/O 
throughput, gate densities, programming tools, interface tools, implementation infrastructure for 
FPGAs, DSPs and parallel processing; (2) evaluate and analyze necessary technology for 
spacebome applications; (3) evaluate implementation differences between ground and 
spacebome instrument data preprocessing using FPGAs, DSP and parallel processors; and (4) 
identify the transition approach for the migration of a lab version of a reconfigurable system to a 
ground and spacebome operational environment. 

POC: Patrick Coronado 

TRL 6/2006 

Evolvable Hardware (JPL) 

The evolvable hardware research objective is to develop microelectronics chips capable of self- 
reconfiguration for adaptation to the environment. The approach is to use reconfigurable cells, 
achieve self-organization by reassigning cell function and connections between cells, and touse 
powerful parallel searches (e.g., genetic algorithms) directly in hardware to evolve chip 
architecture. 

POC: Benny Toomarian 

TRL 6/2010 

RAD750 (JPL) 

As an outgrowth of the X2000 project, a radiation-hardened version of the PowerPC 750 termed 
the RAD750 is being developed. The current version of this processor (which will be flown on 
the Deep Impact and Starlight missions) will be a factor of ten faster than the RAD6000. The 
next version of this processor will be available in a flight version starting in 2004 and will be a 
factor of 20 faster than the RAD6000. 

POC: Lloyd Keith 

TRL 6/2004 
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Ultra-Low Power Radiation Tolerant Reconfigurable FPGAs (LaRC) 

This proposal will apply ultra low power technology and radiation tolerant circuit methodologies 
to a reconfigurable FPGA that is directly compatible with tools from Xilinx, Inc., one of the 
commercial industry’s leading FPGA producers. 

POC: William Wilson 

TRL 4/2002 

Rad-Hard Reconfigurable Field Programmable Gate Array (GSFC) 

The objective of this task is to develop a radiation hardened reconfigurable field programmable 
gate array. This gate array will be based on commercially-available devices with existing design 
tools and development platforms. The resulting product would be a single chip used within 
spacecraft digital electronics and instrument subsystems and would provide for digital 
electronics hardware that is 100 times smaller than the equivalent discrete components and 
readily modified in orbit to meet new mission requirements. This effort will produce a radiation 
hardened equivalent to the Atmel AT6010, a RAM-based reconfigurable FPGA, that provides 
20,000 user-reprogrammable gates. 

POC: John McCabe 

TRL 6/2005 

4.3.1.2 Onboard Computing: Software 
Capabilities 

Future missions will demand much more functionality from onboard software (such as precision 
landing, hazard avoidance, goal-oriented behavior, and autonomous operation) for longer periods 
of time with less intervention from the ground. In addition, several missions (such as TPF, 
Const-X, LISA, OWL, ARISE, and GEC) are designed on the architecture of multiple 
independent spacecraft acting in concert. These missions will demand that the onboard flight 
software operates in a distributed computing environment. 

Technologies 

Many spacecraft currently use a reusable, commercial operating system rather than a custom- 
built kernel to provide the environment for their onboard software. This trend will presumably 
continue and be extended into the middleware layers and frameworks which provide common 
services such as resource management and fault protection. As noted above, missions consisting 
of several cooperating spacecraft will require new technologies in the onboard software such as 
autonomous command and control of formation flying and control of distributed sensors. 
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Products 

Mission Data System MDS (JPL) 

MDS is a unified architectural framework for building end-to-end flight and ground software 
systems. The MDS consists of a toolkit of generic software capabilities that space mission 
projects will customize for their specific mission. The framework emphasizes operability, 
adaptability, reuse, and experience-based improvement. The MDS framework includes the 
necessary elements for building goal-oriented and autonomous commanding software. It 
includes intelligent data management and transport, integrated guidance, navigation and control, 
and most other capabilities needed for mission software. The Mars U9 mission has selected 
MDS for use as its baseline flight and rover software. 

POC: John Lai 

TRL 6/2002 

Flight Linux ( GSFC) 

The flight software component of a spacecraft is complex and expensive to develop, test, 
manage, and maintain. At the same time, the flight software component provides the needed 
flexibility for on-orbit systems to be reconfigured to meet new or unanticipated requirements or 
changed environments due to component degradation or failure. It also provides the means to 
migrate science data processing components from the ground to the flight computer onboard to 
reduce data downlink volumes or target specific observations based on onboard analysis. Flight 
Linux provides the following benefits: 

• Access to a large pool of trained software developers 

• High quality network and file system support 

• Facilitates low cost deployment of COTS and free software 

• Full and free access to all source code 

• Run-time installable device drivers which aid on-orbit maintenance 

• Access to a large pool of device drivers and a solid open framework for developing custom 
drivers 

• Self-hosting (same OS can be used to develop and fly software). 

POC: Todd Miller 

TRL 6/2002 

Agent Based Software for the Autonomous Control of Formation Flying Spacecraft (GSFC) 

The objective of this research is to investigate techniques for robustly distributing the 
implementation of multi-vehicle control systems. Our approach will use agent-based software 
onboard the spacecraft to increase the autonomy, reconfigurability, and reliability of the fleet 
control system. ObjectAgent and TeamAgent (being developed under an Air Force contract) will 
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form the core software necessary to enable software agents to be used in our flight-critical, real- 
time fleet control systems. The research in this proposal will extend the TeamAgent software and 
apply it to the particular problems of distributed estimation of relative spacecraft navigation with 
carrier-phase differential GPS (both position and attitude); distributed fleet planning, 
coordination, and control; and fleet fault detection and recovery. The primary focus of this work 
will be to select efficient and effective communication and decision-making agent architectures 
to implement the estimation and control algorithms necessary to solve each of these problems. 
Software agents should provide robust solutions to these problems for large fleets (e.g., more 
than 3-4 spacecraft, which is the current state-of-the-art.) 

POC: Jonathon How 

TRL 6/2005 

Autonomous Command and Control for Formation Flight (Formation Control) (GSFC) 

We propose to develop and demonstrate autonomous command and control flight systems for 
formations by extending and generalizing the concepts already demonstrated for autonomous 
maneuver control onboard EOl. We will expand the AutoCon fuzzy logic control engine to 
include autonomous science data collection, spacecraft health and management, and formation 
coordination. Our concept is to enable the experimenters to make science collection goal-based 
and move all of the scheduling and spacecraft control to the formation. We will demonstrate 
technology levels 1, 2, and 3 in 4 years by producing a command and control engine that 
demonstrates autonomy in the formation flying testbed. 

POC: John Bristow 

TRL 6/2007 

Formation Flying Control ( JPL ) 

Formation flying control develops precision guidance and control architectures and design 
methodologies to enable high precision synchronized motion using centralized/decentralized 
formation estimation and control techniques, algorithms for optimal synchronized maneuvers, 
reconfiguration, collision avoidance mechanisms, formation management and stationkeeping. 

The first set of formation flying guidance and control methods (cm-arcmin precision level 
accuracy) will be ready for implementation into the Starlight project by 2003. The activity is 
closely coordinated with the project and formation estimation, guidance and control algorithms 
developed by this activity are adopted and baselined by the project. Larger and more precise 
formations such as TPF (mm-arcsec precision level accuracy) will include formation keeping and 
autonomous reconfigurations, optimal (minimal fuel, minimal time) onboard path planning and 
collision avoidance algorithms ready by 2010 in time for application to variety of Earth and 
space science missions planned for 2013 and beyond. 

POC: Fred Hadaegh 

TRL 6/2005 
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Distributed Optical Sensor-Based Control (JPL) 

This onboard computing software project develops the vision-based technologies for image-in- 
the-loop formation coordination and control. Algorithms and software for the development of 
onboard, real-time 3D images of a science target are developed. The task develops the capability 
for onboard integration of active and passive sensor data distributed over non-uniform orbits. 
The product will ready for flight infusion in 2008. 

Self Organizing Spacecraft (JPL) 

This onboard computing software project develops advanced architectures and software for the 
autonomous reconfiguration, task planning, scheduling, and execution of formation tasks. The 
task develops the rules for information transfer and communication between elements in a 
formation including master/slave type rules for reconfigurations and develops latency-tolerant 
data communication and related technologies for interspacecraft communication latency impact. 
It builds the high level of autonomy for the entire formation to reduce the ground involvement 
for stationkeeping and formation operations. These technologies will be ready for infusion to the 
TPF type mission by 2008. 

High-Precision Positioning and Alignment for Spacecraft Formation Flying ( GSFC) 

A new class of proposed missions for astronomy and Earth science uses multiple spacecraft 
flying in formation to make high-resolution observations. The missions offer new techniques for 
imaging and are a cost-effective alternative to single spacecraft instruments using large optics 
and massive support structures. A major challenge to implementation of distributed spacecraft 
observatories is measuring and controlling the formation geometry. Many of the proposed 
missions require that the spacecraft fly in formation at large separations yet maintain their 
relative positions and attitudes to very tight tolerances. One example is provided by the Maxim 
Pathfinder mission, which uses interferometric techniques to provide X-ray images of the sky at 
submilliarcsecond resolution. This resolution requires millimeter-level lateral alignment of a 
focal plane spacecraft relative to an optics spacecraft located hundreds of kilometers away. Our 
proposed project addresses high-precision sensing of relative spacecraft positions and control of 
relative position to the stability levels needed by Maxim Pathfinder and other distributed 
spacecraft interferometers. The proposed work includes review and flowdown of system 
requirements on position knowledge and control, analysis of external and internal spacecraft 
disturbances, investigation of candidate sensor designs to measure relative spacecraft position, 
fabrication and test of a prototype sensor, and studies of spacecraft systems needed for high- 
precision position control. The sensing technologies and controls also have application to other 
space systems (directed communication links, intercept and docking systems) in which precise 
knowledge of relative positions over a large range of distances is needed. 

POC: James Leitech 

TRL 6/2006 
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4.3.1.3 Ground Computing 
Capabilities 

Increasing mission capabilities will also demand more computing power on the ground for 
simulation and data processing. The evolution of deep-space missions from flybys and orbiters 
to landers and aerobots will require detailed simulations for the design, validation, and operation 
of these missions, and these simulations in turn will require significant additional computing 
capability. In addition, several of the next generation of orbiting observatories will produce data 
in far greater quantities than previous missions. The interpretation of these datasets will require 
not only additional data reduction but also detailed, compute-intensive comparisons with models 
of the physical environment 

Technologies 

Computing requirements of this order require the use of parallel and distributed systems. 

Though parallel architectures have been in existence for many years, their effective application 
to general problems has remained elusive. Several technologies are targeted at improving the 
usability of parallel processors through the development of software tools. Other technologies 
attempt to reduce the overhead of processor-to-processor or processor-to-memory 
communication and others are focused on reducing the cost of distributed computing by 
facilitating the use of multi-institutional computing resources as one large computing engine. 

Products 

Exploratory Computing Environment (ARC) 

A exploratory computing environment that enables multiple applications to interact in a 
dynamically created multi-client and multi-server fashion is being created. Such applications 
can be customized for the task at hand, and they can coordinate disparate sources of data (from 
archival repositories and/or ongoing simulations), a diversity of analytical and visualization 
tools, and the ongoing and possibly simultaneous efforts of several scientists. 

POC: Pat Moran 

TRL3-5 

Advanced System Design Tools (ARC) 

Advanced system design tools for the simulation and design of computing systems are being 
developed. This will result in the delivery of standards and software modules to accurately 
predict system performance based on specific computational applications, and tools to optimize 
system performance. The outcome of this research work will improve dynamic computing 
system design and enhance the evaluation capability for innovative supercomputing concepts. 

POC: Rupak Biswas 

TRL2-4 
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Supercomputing Testbed (ARC) 

ARC continues to provide a compute environment that meets the current needs of the IT research 
community and to path-find computer architectures suitable for the next generation of NASA 
applications. To achieve this end, a supercomputing testbed is being developed to achieve the 
following technology goals: 

• Provide a persistent and reliable computer environment 

• Provide reliable storage for short-term, intermediate and long-term needs 

• Develop and implement networking solutions in support of other IT efforts 

• Improve performance of parallel and vector applications to increase the scientific research 
that can be performed on NASA resources 

• Develop programming techniques to increase the utilization of NASA compute resources 

• Publish and train resources on new programming techniques. 

POC: Bill Thigpen 

Information Power Grid (IPG) (ARC) 

ARC has created an information systems infrastructure that encompasses geographically 
distributed computing centers and laboratories with far greater performance, and reliability at far 
lower cost than is available today. The IPG, the prototype of such a seamless computing 
environment, will provide significant new capabilities to scientists and engineers by facilitating 
the solution of large-scale, complex, multi-institutional/multi-disciplinary, data and 
computational based problems using computer processing units (CPU), data storage, 
instrumentation, and human resources distributed across the NASA community. This, in turn, 
translates into technology goals in five areas: 

• Independent, but consistent, tools and services that support various programming 
environments for building applications in widely distributed environments; 

• Tools, services, and infrastructure for managing and aggregating dynamic, widely distributed 
collections of resources — CPUs, data storage/information systems, communications systems, 
real-time data sources and instruments, and human collaborators 

• Facilities for constructing collaborative, application oriented workbenches / problem solving 
environments across the NASA enterprise based on the IPG infrastructure and applications 

• A common resource management approach that addresses, e.g., system management, user 
identification, resource allocations, accounting, security, etc. 

An operational environment incorporating major computing and data resources at multiple 
NASA sites in order to provide an infrastructure capable of routinely addressing larger scale, 
more diverse, and more transient problems than is possible today. 

POC: Tom Hinke 

TRL: 4-6 
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G il games h (JPL) 

The Gilgamesh project is intended to develop a new processor-in-memory architecture and 
demonstrate its applicability to high performance computing applications in ground and space. 
The Gilgamesh hardware architecture is being prototyped in FPGA hardware, with an eye toward 
CMOS IC implementation in the out-years. A software architecture and development 
environment will also be produced as part of the project effort. 

POC: Loring Craymer 

TRL 6/2006 

MLPlib (Ames) 

ARC continues to develop standardized and simple techniques to assist users in moving their 
scientific and engineering applications with large computing requirements (e.g., simulations 
required in OSS grand challenges) to parallel platforms. The MLPlib shared-memory 
parallelization library has been developed and demonstrated on NASA applications (CFD, 
molecular dynamics, and climate modeling) showing significant speed of computational time 
with simplification of the required programming code. Future efforts will be focused on 
extending MLPlib to distributed architectures and the development of a new programming 
paradigm that supports a shared memory configuration for heterogeneous architectures. 

POC: Jim Taft 

TRL 4-6 

HPCC/ESS Parallel Adaptive Mesh Refinement (AMR) (JPL) 

The objective is to develop a comprehensive parallel AMR library that can be easily integrated 
into existing mesh-based parallel applications running on massively parallel computers and 
computer clusters. The software platform for our parallel library will be based mainly on Fortran 
90 and the message-passing interface standard. The parallel library will include a set of 
components for operations at various AMR stages, which include a parallel mesh partitioner, a 
parallel adaptive mesh refiner with quality control, a parallel load-balancing module, and a 
parallel local-error estimator. Our software architecture design for the parallel AMR library will 
make these AMR components highly modular, maximizing the user control on individual 
components and providing the simplest possible interfaces among the components and to the 
application code. 

POC: Tom Cwik 

TRL 6/2003 

HPCC/ESS Commodity Building Block Testbed (GSFC) 

The objective of this task is to achieve dramatic price/performance improvement for Earth and 
space science applications and improve the commodity cluster software environment 
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strategically for the benefit of the ESS community. The ESS project’s Beowulf activity is 
motivated by the opportunity of bringing inexpensive commodity-based parallel computing to 
the end-user environment. The expected effect is increase in processing and data handling 
capacity available to the scientist in the local environment. The approach taken is based on the 
Linux operating system, a robust and fully open Posix-compatible environment available at no 
cost and with full system source code. It provides an excellent base with which to support system 
software research and advanced development, leveraging industrial and academic research and 
development. The Beowulf activity provides ESS investigators with access to demonstration 
systems capable of achieving new levels of cost-effective, high-performance computing and 
supports their stress testing and evaluation of these systems. A research awards program will fill 
high-priority shortcomings in the Linux system for support of clusters. 

POC: James Fischer 

TRL 6/2002 

High-Performance Information Technology Integration (JPL) 

The objective of this task is to make high performance IT more accessible through: use of 
emergent ultra-high bandwidth communications, better high performance asset integration, 
exploitation of the new collaborative engineering environments, and better integration with 
standard IT infrastructure. 

We will develop missing part technologies combined with HPIT assets via multigigabit 
networks. These missing parts are high-performance I/O to remote tapes, real-time connections 
to data sources, and collaboration over long distances while using very large data sets. We will 
develop the missing parts and then apply the resulting integrated technology to an important 
NASA mission or application. Major goals for the task include: (1) demonstrate robot tape at 
40 mbyte/sec and over a wide area network, (2) produce an INSAR image in under 24 hours, 
with (3) application-independent visualizations projected at 10 frames/sec (i.e., 320mbit/sec) 
over wide area networks. 

POC: Dave Curkendall 

TRL 6/2002 

4.3.2 Communications 

4.3.2.1 Space Communications 
Capabilities 

Almost every proposed mission described in this section can produce far more data than it can 
send to ground. This is particularly true of ARISE, SEC, and ISP. Communication bandwidth 
constraints will become even more severe in the future due to the higher volume of data that will 
be produced, the increased number of operational missions, and the relatively fixed number of 
ground assets that can receive the data. In addition, the evolution of cooperating sets of 
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spacecraft (both in space and planetary surfaces) will drive the need for more capable spacecraft- 
to-spacecraft communication. 

Technologies 

Several technologies address the goal of increased communication bandwidth. Most 
fundamentally, research into Ka-band and optical communications will mature these 
technologies to provide far higher fundamental bandwidths than are achievable with X-band. 
Also, several antennas can be arrayed into one synthesized large antenna to increase the 
aggregate bandwidth. In addition, several technologies attempt to more effectively use the 
bandwidth available through the use of enhanced coding and compression techniques. There is 
significant interest in software radios that can be reconfigured with different performance 
parameters for different phases of the mission. A particular application to this technology is in a 
communications package that can be used on future Mars orbiters to provide a relay to Earth. 
Finally, several tasks address the question of architectures and how technologies that were 
developed for ground use (such as the Internet) could be adapted for space. 

Products 

Ka-Band Ground Terminal Technology Demonstration (GSFC) 

The objective of this technology demonstration project is to design, develop, and demonstrate a 
capability to support high-rate (greater than 600 Mbps) science-gathering spacecraft operating in 
the approved Government Ka-Band spectrum. The system will consist of an S-Band and Ka- 
Band ground tracking antenna system; S-Band telemetry, tracking, and command subsystems; 
and a high-rate (greater than 600 Mbps) science-data reception, processing, and storage 
subsystem. 

POC: Steven Bundick 

TRL 6/2003 

Ka-band Spacecraft Amplifier (JPL) 

Develop Ka-band spacecraft amplifiers in order to allow communication from deep space at Ka- 
band. There are two tasks: development of a 27 W (beginning of life) Ka-band TWTA and 
development of a 20 W Ka-band Phased Array antenna feed that will allow vemere steering of 
the antenna beam. 

POC: Richard Lovick 

TRL 6/2002 

Ka Band Experiments (JPL) 

Perform system analysis to characterize expected operational performance and evaluate 
technology alternatives for future deep space communications. Develop, maintain, and analyze 
data on new technologies (performance, costs, uncertainties, and risks) and potential future flight 
project needs in order to characterize the expected operational performance of future DSN 


115 



Chapter 4. NASA Information Technology Research and Development 


systems, evaluate technology alternatives, and identify potential improvements. Extend the 
comparative study of links at X, Ka, and optical bands to a wider range of assumptions, using a 
parametric approach. Establish the viability of Ka-band for deep space missions through 
experiments with spacecraft and by measuring the advantage of Ka-band relative to X-band. 

POC: Fabrizio Pollara 

TRL 6/2003 

Optical Ground Systems (JPL) 

The objectives are to assess, develop, and validate optical communications ground systems 
technology for support of future NASA missions. The efforts involve analysis of end-to-end 
optical communications systems in order to promote a better understanding of the benefits that 
this technology can provide for future NASA missions. Based on these analyses, key 
technologies that will enable cost-effective high performance ground systems required for deep 
space optical communications are being developed, including a prototype PPM receiver and a 
10m optical receiving station. 

POC: Abhijit Biswas 

TRL 6/2007 

Very Large Array Antenna (JPL) 

The objective is to develop the technology for construction of a very large Earth-based antenna 
to upgrade the present Deep Space Network (DSN) by a factor of 10. The baseline parameters 
for this array are 3000 antennas of 8-meter diameter operating at 8 GHz with 32 GHz operation 
considered as an option. The benefits of such an array are smaller spacecraft due to smaller 
spacecraft antennas with lower power transmitters and a higher science data rate capability. The 
new technologies that will make the array affordable are the low-cost small antennas developed 
for commercial broadcast satellite TV applications, low-cost integrated-circuit very low-noise 
receivers, and low-cost, low-maintenance, 80 K refrigerators being developed for computer 
cooling applications. 

POC: Sander Weinreb 

TRL 6/2005 

Channel Coding and Decoders (JPL) 

This work area will continue to exert leadership in channel coding for deep-space 
communications and to provide accurate performance analysis of coding schemes, including 
implementation losses. It will develop new, higher-performance or lower-complexity schemes, 
and influence code selections by CCSDS and other space agencies. The work will develop 
methods for protection of on-board communication circuitry by using error detection/correction 
techniques. These new methods will be based on the addition of a controlled amount of 
redundancy to detect errors in memories, computing units, and buses, at suitable checkpoints. 
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The work will develop decoder architectures, coding and decoding concepts will be 
demonstrated, and designs suitable for implementation with current technology at low cost will 
be developed. 

POC: Fabrizio Pollara 

TRL 6/2005 

Channel Coding Research ( GSFC) 

This task will develop coding techniques that will enable Viterbi decoding up to 600 Mbps with 
a goal of 1000 Mbps. It will also investigate coding techniques that will improve bandwidth 
utilization efficiency of high rate data return links. 

POC: Peh-Shu Yeh 

TRL 6/2007 

Data Compression (JPL) 

This work will research and demonstrate high-performance data-compression algorithms for use 
in deep-space science missions. We will provide accessible implementations of compression 
algorithms robust in the presence of channel noise and with distortion control acceptable to 
science users. We will integrate progressive compression methods and intelligent buffer 
management to maximize the overall science value returned to Earth from scientific instruments 
despite constraints imposed by the spacecraft’s finite data storage capacity and limited data 
transmission rate. 

POC: Aaron Kiely 

TRL 6/2001 

High-Performance Data Compression (GSFC) 

Develop high-speed data-compression technology to maximize scientific information return from 
space platforms that have either constrained communication channel bandwidth or limited 
onboard buffer capacity. We are developing a technique to provide selectable compression ratios 
between 2:1 and 40:1 based on needs, and to provide reconstructed data with minimum 
distortion. 

POC: Pen-Shu Yeh 

TRL 6/2005 

Software Reconfigurable Transceiver Technologies (JPL) 

While supporting the Mars Network Phase A Study, several designs were conceived and 
simulated which take advantage of an implementation concept that employs a very high- 
throughput microprocessor and reprogrammable digital signal processing hardware. This tight 
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integration of reprogrammable software and hardware has been termed reconfigurable for its 
ability to permit uploads of new software and hardware programs which can change the basic 
operations of the instrument after launch. The objective of this work is to demonstrate the key 
software technologies in prototype form in order to mitigate sufficient risk to allow a flight 
project to select a reconfigurable radio solution for Mars in situ navigation and communication 
with a high probability of success. The work proposed here is complementary to work funded 
elsewhere that will focus on hardware technology demonstrations that are also key to addressing 
the current risks of reconfigurable radios. 

POC: Jeff Srinivasan 

TRL 6/2002 

Low Power Tranceiver (GSFC) 

Develop several generations of engineering development model low power transceivers that 
demonstrate the feasibility of unprecedented next-generation communications and navigation 
functionality in a single device. This effort leverages and builds upon previous technology 
program developments by further integrating spacecraft subsystems, focusing on additional 
reductions in size, weight and power consumption and will demonstrate the communications and 
navigation functionality that will enable future generations of NASA spacecraft. 

POC: David Zillig 

TRL 6/2002 

Mars Telecom Proximity Payload (JPL) 

To meet the expected near- and far-term Mars Network data and navigation requirements, the 
Mars Telecom Proximity Payload (MTPP) development is being undertaken. The current thrust 
of this development allows it to not only serve the near- and far-term Mars network needs, but 
positions it to provide a possible new solution to the dire ct -to-Earth communications needs of a 
large class of deep space missions. The overall MTPP objectives are to provide: 

• Resilient global communications coverage of the Martian surface 

• Significantly increased data return to Earth relative to user direct-to-Earth capabilities 

• High connectivity with Martian assets for data transfer, commanding, and navigation 

• High data-rate in situ links 

• Significantly shorter data transfer times 

• Higher data volume per joule of expended energy 

• Enabling energy efficient data return from small missions for which DTE links are not 
possible 

• Enabling high-volume data return during critical Mars entry, descent, and landing mission 
phases not possible via DTE links; 

• Precision navigation for approaching, orbiting, landing, and operational assets at Mars 
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• Timing services to provide absolute time reference and synchronization for assets at Mars 

• Radio-based science using the communication/navigation signals. 

POC: Thomas Jedrey 
TRL 6/2005 

IP Infrastructure for Distributed Space Systems ( GRC) 

The objective of this task is to develop software and hardware infrastructure to enable ubiquitous 
access of remote, distributed, mission critical systems where the Internet provides the core 
communication backbone. This enabling infrastructure will provide reliable, transparent 
interfaces to distributed components for operation by scientist, engineers, and other users. 

POC: Kul Bhasin 

TRL 6/2003 

Space Data Direct Delivery to Multiple Clients ( GRC) 

The objective of this task is to develop a new protocol framework for multicast communications 
in satellite-based IP networks. This framework for delivering space-based multicast services will 
involve the development of a multi-layered protocol suite composed of new schemes at the link 
and transport layers. At the link layer, this includes the adaptive forward error correction and 
automatic repeat request schemes to compensate for lossy and error-prone satellite links. 

POC: Calvin Ramos 

TRL 6/2004 

Ad-Hoc Networks in Space and Surface Systems ( GRC) 

This task will develop network protocol extensions that will provide a dynamic, self-organizing, 
self-configuring wireless network, in which network nodes cooperate to forward packets for each 
other. This will allow communication between nodes not directly within wireless transmission 
range of one another. The protocol extension developed can be deployed in space and surface 
systems enabling seamless, transport mobility within a space-based Internet and Earth-based 
Internet. 

POC: David Foltz 
TRL 3/2003 

High-Throughput Distributed Spacecraft Networking (GRC) 

This research effort addresses the technical challenges of spacecraft communicating in a highly- 
effective mesh architecture. Specific technologies include integrated multiple access, modulation 
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and encoding for high-throughput distributed spacecraft networking with support for quality of 
service, self-organization, and multiple-path routing. 

POC: Thomas Wallett 

TRL 4/2003 

Cooperative Communications for Remote Exploration ( JPL ) 

Future space exploration missions will include robotic outposts and autonomous sensor networks 
that require wireless proximity networks in order to distribute and process data jointly among the 
nodes to achieve the science and mission objectives. Local communications may be used, for 
example, when a network of seismic or atmospheric sensors on Mars needs to respond to local 
conditions in a timely manner. Sensor nodes may communicate to one another to turn on and off 
certain instruments of the neighboring sensors when one detects the signature of an impending 
windstorm or Marsquake. These devices also need to establish reliable connections to base 
stations or other spacecraft to reliably relay commands and telemetry to and from the Earth. 
Generally, a separate more-powerful radio is used to close this type of long distance link due to 
the propagation loss that falls as distance squared. It is desirable from size, reliability, ease of 
deployment and cost viewpoints to use the same radio for both local and long-haul 
communications. The objective of this project is to develop cooperative communication 
algorithms that increase range, robustness, power efficiency and data throughput of information 
to/from a sensor network to a remote relay node or to an external network. 

POC: Jonathan Agre 

TRL 6/2007 

Protocols for Ad-Hoc Networks (JPL) 

We will develop ad-hoc network schemes that are applicable to communications in Europa ocean 
explorer missions, fleets of Mars rovers, and other unique environments. The protocols will 
support autonomous routing, topology management (i.e., adding and removing nodes), and self 
organization. In addition, important system attributes such as power conservation, fault 
tolerance, scalability, and reconfigurability will be worked into the designs. 

POC: Loren Clare 

TRL 6/2003 

Constellation Infrared Communication ( GSFC) 

The goal of this task is to develop and validate the use of infrared freespace communications 
within a spacecraft. A spacecraft onboard IR network would eliminate spacecraft harnessing by 
spraying IR signals around the spacecraft instead of routing cables to each electronics box. 
Electronics boxes could undergo initial spacecraft integration prior to actually being attached to 
the spacecraft. They would only need to be brought within range of the spacecraft IR network. 
Costly safe to mate spacecraft integration procedures would be eliminated. The electronics box 
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would not even need to be connected to the spacecraft power system during initial spacecraft 
integration; it could be powered from a test rack. Since IR coupling provides complete electrical 
isolation, there is no concern for ground loops with such a configuration. There is also complete 
immunity from ESD concerns, since the IR transceiver would not be exposed, but would be 
located behind a protective window. 

POC: Philip Luers 

TRL 6/2002 

Next Generation Space Internet Communications Services (JPL) 

This effort will develop new data communications standards in the areas of: 

• Dynamic signaling and switching for efficient space link communications services 

• Integration of internet end-to-end resource reservation with high performance space 
communications services 

• Integration of Internet mobile IP into spacecraft communications gateways 

• Provision of end-to-end security for earth science enterprise communications. 

POC: Adrian Hooke 
TRL 6/2003 

Operating Missions as Nodes on the Internet (OMNI) (GSFC) 

The long-term goal of the OMNI project is to infuse new technologies and concepts that will 
make it practical and cost-effective to build and operate missions as nodes on the Internet. A key 
objective of the OMNI project is to demonstrate the cost-effectiveness of building and operating 
missions as nodes on the Internet using commodity standard network protocols and off-the-shelf 
hardware and software. 

POC: James Rash 

TRL 6/2005 

Technologies for Space Internet Services (GRC) 

The objective of this work area is to develop, test, integrate, qualify, demonstrate, and infuse all 
of the Internet and supporting communications infrastructure technologies required to extend the 
Internet paradigm to all future NASA missions. This work area is committed to the development, 
qualification, and infusion of the network architectures, protocols, and hardware components 
necessary to enable the use of the Space Internet for all future NASA missions and make each 
spacecraft instrument as accessible as any other node on the Internet. Because of the wide 
breadth of NASA mission communication requirements, multiple mission classes (with common 
characteristics) will be identified and quantified. Network architectures will then be developed 
for each mission class. Networking hardware for spacecraft systems in each mission class will be 
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developed and qualified. Finally, highly-efficient packet and file protocols tailored to the long 
and variable delays of space-link propagation will be developed and qualified for each mission 
class. 

POC: Phillip Paulsen 
TRL 6/2003 

Onboard Network Routing ( GRC) 

The ultimate goal of this task is to allow spacecraft to function as nodes on the Internet. To 
investigate and provide onboard network routing solutions for enabling data flow within an IP- 
compliant spacecraft. Demonstration and characterization of an integrated Tl rate router for 
space-based networks is planned for FY01; an integrated class of onboard routing hardware 
(routers, switches, network interface cards) at up to T3 rates for a multi-spacecraft environment 
is planned for FY02. The FY01 task focuses on the completion of the Tl rate proof-of-concept 
demonstration of a 2 Mbyte/sec miniature router developed by Bluestreams Communications, 
Inc., to address some of the key issues surrounding space-based routers for user spacecraft. 
Functional tests of the miniature router will be performed and a demonstration of an onboard 
LAN with various subsystems is envisioned. 

POC: Robert Jones 

TRL 6/2005 

4.3.2.2 Ground Communications 
Capabilities 

In addition to enhanced communication capabilities to deliver data to the ground, there will be 
significant demand for enhanced ground communication for data distribution, collaborative 
engineering, and collaborative operations. Though this capability is available in the commercial 
marketplace, NASA places demands on its ground network that go beyond those of most 
customers, particularly in the areas of quality-of-service and security. 

Technologies 

Ground networking technologies range from increasing the raw bandwidth of the ground 
network to better utilization of resources through better channel management. In addition, some 
technologies focus on quality-of-service guarantees throu g h prioritization of the network traffic. 
Other technologies focus on the security and infrastructure necessary to provide services such as 
on-demand video conferencing. 
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Products 

Gigabit Networking (ARC) 

The objective is to provide networking capabilities at ultra-high bandwidth, from 500 
megabits/second to multiple gigabits/second. To achieve this objective, NREN has connected to 
the National Transparent Optical Network (NTON), a 10+ gigabit/second optical network on the 
west coast. In turn, NTON connects to the Advanced Technology Demonstration Network 
(ATDNet), a comparable network in the Washington, D.C. area, via the High Speed Connectivity 
Consortium 2.5 gigabit/second network. This networking infrastructure enables end-to-end 
gigabit connectivity between selected NASA sites and application partners across the country. 
Testing of the raw bandwidth capacity is currently underway. Future research will focus on 
identifying and overcoming protocol, workstation host, and application performance bottlenecks, 
so as to enable the user application to utilize the available bandwidth. 

POC: Kenneth Freeman 

TRL 6/2005 

Advanced Multicast (ARC) 

The objective of NREN’s multicast activities is to enable high-performance applications that 
require point-to-multipoint transmission. Multicast was initially introduced into the Internet by 
creating virtual multicast tunnels within the unicast infrastructure. Tunneling, however, is only 
an interim solution, as it is extremely inefficient. NREN is taking the lead in deploying native 
multicast in wide area networks, thus enabling very high bandwidth multicast. Work is in 
progress to transfer multicast to NASA’s operational networks. 

POC: Kenneth Freeman 

TRL 6/2002 

Hybrid Networking (GRC) 

The objective is seamless integration of satellite and terrestrial networks into a high-performance 
networking system. Traditional network protocols (designed and tuned for terrestrial networks) 
may require modification to enhance performance in this high-latency, lossy network 
environment. 

POC: Issac Lopez 

TRL 6/2005 

Adaptive Middleware for End-to-End QoS (ARC) 

The objective of adaptive QoS middleware is to provide an interface between an application and 
system resources to enable the application to adapt to changes in resource availability while it is 
running, thus improving the performance of the application. NREN will prototype network 
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technology to enable the creation of a middleware-enhanced internetwork to support a very high- 
performance geographically-distributed heterogeneous information and computational capability. 
The middleware will address scheduling and other QoS issues as well as security issues. Such a 
platform has the potential of transforming NASA missions in the 21st century. NREN is working 
with university partners to develop an adaptive middleware framework to enable QoS to be 
programmed into multimedia applications, thus making QoS an integral part of their behavior. 
This framework has been successfully demonstrated using a test application. Future activities 
will include integration of the adaptive QoS middleware framework into a NASA mission 
application. 

POC: Marjory Johnson 

TRL 6/2006 

Network Quality of Service (ARC) 

The objective is to enable commitment of resources to specific applications to ensure that values 
of such performance parameters as bandwidth, latency, jitter, and packet loss stay within an 
acceptable range. NREN will investigate various approaches to QoS, including shaping traffic as 
it enters the network, reserving network resources, utilizing different queuing strategies within 
the routers, and labeling selected network flows and then providing preferential treatment to 
those flows within the network backbone (e.g., DiffServ). NREN is developing a network 
monitoring and management tool called PCMon that supports detailed analysis of individual IP 
packet flows. This tool will enable assessment of the effectiveness of various QoS technologies 
employed in the network system. PCMon has been demonstrated successfully both within the 
NREN internal lab at NASA Ames and using five nodes distributed across the NREN WAN 
testbed. A storage and retrieval capability is currently being added to PCMon. Future 
enhancements include scaling the tool to optical carrier 12 (i.e., gigabit) rate. 

POC: Kenneth Freeman 

TRL 6/2005 

IsoWAN(JPL) 

Iso WAN is an advanced, isolated network interconnect services framework that will enable 
applications to be more secure, and able to access and be in use in both local and remote 
environments. The main functions of an IsoWAN are virtual localization of remote application 
services, an application service interface, coordinated delivery of applications and associated 
data to the customer, and supporting collaborative application development for customers. The 
IsoWAN solves the key technology problem of managing federated security of independent 
security domains. This enabling technology allows IsoWAN to serve as a plug for distributed 
computing applications between NASA centers and NASA’s partners. 

POC: Ed Chow 


TRL 4/2002 
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4.4 Virtual Mission Lifecycle (VML) 

This section describes NASA information technology efforts that advance the mission lifecycle 
process by providing evolutionary mission information systems, comprehensive design 
verification and validation, concurrent lifecycle phase engineering, and effective work-flow 
between teams as well as between human and machine. The IT efforts are categorized as VML 
IT. The term virtual reflects the technical approach emphasizing software- oriented modeling and 
simulation to create representations of real missions. 

Based on the technical objective and approach, the VML IT is divided into six subareas: 

1 . Mission system knowledge engineering 

2. Spacecraft system performance modeling and simulation 

3. Mission system operation behavior modeling and simulation 

4. Rapid integration and test environment 

5. Human-in-the loop process modeling and training 

6. Collaborative system design and operation planning. 

Each subarea is described in three aspects: capabilities pursued, technologies developed or 
infused, and example products that are currently under development at JPL, ARC, and GSFC. 
Each example product is presented with its general mission relevance and specific mission 
application along with the technology readiness level range. 

4.4.1 Mission System Knowledge Engineering 

Mission system knowledge engineering IT supports development of advanced information 
systems for representation, exploration, derivation, and distribution of the mission system 
information. This section introduces evolutionary mission knowledge systems that provide the 
bridging between domain-specific knowledge and information technology to enable multi- 
disciplinary knowledge exchange. 

Capabilities 

• Requirements tracking 

• Mission system design knowledge representation 

• Mission design knowledge representation 

• Mission science knowledge representation 

• Intelligent mission information system. 

Technologies 

• Modeling languages 

• Intelligent agents 

• Distributed-component-based mission data system 

• Object-oriented database. 
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Products 

SPICE Ancillary Information System (JPL) 

SPICE is a multi-mission spacecraft state archiving mechanism that supports science data 
analysis. This task extends the SPICE kernels to support future mission needs including surface 
rovers, control net, formation flying, and mission simulation and visualization. The extension 
provides multiple reference system integration, attitude analysis, and API data structures. Future 
work includes representation of continuous dynamics model and system state uncertainty. 

TRL: 6-8 

POC: Chuck Acton 
Sax/Luthor (JPL) 

An object-oriented mission model code generator (lexical analyzer and parser generator pair) that 
automatically generates C++ programs from mission model scripts. The Virtual Mission project 
at JPL employs Sax/Luthor for creating mission system property simulation software where a 
structured mission system property description is provided along with a syntax grammar 
specification. Future work includes dynamic code generation and inference engine integration for 
on-board autonomy support. 

TRL: 3-4 

POC: Richard Weidner 

Intelligent Mission Model Agents (JPL) 

A set of domain-intelligent mission information service agents that provide high-level 
information by applying domain-specific analyses to the mission data products. The available 
service agents include target agent (science information), trajectory agent (navigation 
information), telecom agent (telecom resource information) and telemetry data agent (telemetry 
processing). Future work plans to develop a structure agent (CAD products) that can provide 
relevant structural information to a wide range of subsystems for various structural impact 
analyses. 


TRL: 5-6 


POC: Richard Weidner 
QUORUM (ARC) 

QUORUM measures the degree of contextual association of large numbers of word pairs in 
narratives or other text to produce models that capture th e co ntextual st ructure of the text. It 
compares models to measure their degree of similarity. By ranking text items on their degree of 
similarity to a query model, QUORUM can retrieve the items that are most relevant to the query. 


126 



w 

W 

W 

W 

KJ 

W 

V 

v_/ 


V 




w 

& 

w 

t? 

w 

w 

'O 


Chapter 4. NASA Information Technology Research and Development 


These methods and software tools serve as the basis of new search and retrieval capabilities that 
have been validated in aviation-safety and other contexts requiring rapid search and response. 

TRL: 6 

POC: Michael W. McGreevy 
ScienceOrganizer (ARC) 

A centralized, web-based digital project library of heterogeneous scientific information, 
including datasets, documents, images, and field and lab records. ScienceOrganizer combines the 
functionality of a database, a document management system, and a hypermedia information 
space. A key feature of ScienceOrganizer is its use of semantic hyperlinks to track and organize 
interrelated information resources within the repository. Cross-linkages capture important 
semantic relationships that assist users in navigating through the information space. These links 
also are useful for performing inference and summarization. 

TRL: 6 

POC: Richard M. Keller 
CIP (ARC) 

The CIP concept is based on DARWIN data management prototypes and fielded systems 
developed over the past several years. CIP also incorporates ScienceOrganizer, described above. 
Using CIP, team members will be able to quickly orient themselves and monitor the progress of 
mission teams and key events, compare data, and check progress towards achieving mission 
success metrics. It will help the user find the information they need to enhance their situational 
awareness. Users can customize the interface and share information, collaborating with others to 
speed data understanding. 

TRL: 4 

POC: John A. Schreiner 

4.4.2 Spacecraft System Performance Modeling and Simulation 

Performance modeling refers to analysis methods for predicting the performance range of a 
system based on its design, while performance simulation refers to software implementation of 
the predicted system performance properties. For complex systems with non-linear system 
response, performance modeling requires an iterative optimization with an embedded simulation. 
This section introduces example research products that combine modeling and simulation for 
performance analysis of critical subsystems of a typical spacecraft system. The performance 
models must be verified with the ground and flight calibration process of a mission so that the 
models can be applied as a representation of the mission system throughout the lifecycle. 

Capabilities 

• Guidance and control dynamics 
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• Avionics flight software (C&DH, Scheduler, etc) 

• Onboard processing 

• Instrument systems 

• Telecommunication 

• Power 

• Thermal. 

Technologies 

• Physics-based 

• Information flow 

• Deterministic analysis 

• Non-deterministic analysis. 

Products 

Rover Operation Analysis Model (ROAM) (JPL) 

Multi-body dynamics modeling and simulation for rover performance analysis. The system 
interfaces with a rover control software to analyze the feasibility of the required traverse 
operation interacting with terrain models. ROAM is integrated in the CLARAty architecture for 
providing rover dynamics simulation and interface mechanism to instrument measurement 
simulation software. Future development will extend the dynamics model to integrate soil 
mechanics. 

TRL: 3-5 

POC: Abhi Jain 

Complex Optics Modeling and Prescription (COMP) (JPL) 

COMP estimates the performance properties of a wide range of optical components in a complex 
telescope instrument system by applying an iterative optimization technique over a set of 
acquired image products. COMP is used for model-based adaptive optics system design and 
control for NGST. 

TRL: 6-7 

POC: David Redding 

Telecom Forecast-Prediction ( TFP ) (JPL) 

TFP is an operational multi-mission telecommunications link analysis tool based on MATLAB. 

It accepts spacecraft, planet, and tracking station ephemerides, spacecraft attitude data, and link 
configuration data to generate predictions of link parameters to support project planning and 
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analysis. Its batch mode counterpart UTP generates link predictions to support project planning 
and sequencing and to configure DSN telemetry subsystems. 


TRL: 6-7 

POC: Kar-Ming Cheung 
Livingstone (ARC) 

Livingstone accepts a model of the components of a complex system such as a spacecraft or 
chemical plant and infers from them the overall behavior of the system. Livingstone also notes 
which commands are being given to the system and what observations are available. From this, 
Livingstone is able to monitor the operation of the system, diagnose its current state, determine if 
sensors are giving impossible readings, recommend actions to put the system into a desired state 
even in the face of failures and so on. 

TRL: 7 

POC: Nicola Muscettola 
Java PathFinder (JPF) (ARC) 

The goal of this project is to create a formal framework in which state machines represent the 
different agents interacting in human-machine applications, namely machines, displays, users, 
and tasks. The generation and exploration of these formal models is performed using the JPF 
model checker, which uses a sophisticated mix of static analysis, abstraction, and explicit-state 
model checking. The main research extensions include new automated abstraction techniques, 
tighter integration of static analysis and model checking for state exploration, and automated 
environment generation. Using these techniques, JPF can detect subtle problems such as mode 
confusion problems. 

TRL: 5 

POC: Michael Lowry 

4.4.3 Mission System Operation Behavior Modeling and Simulation 

Mission system operation behavior modeling and simulation technology addresses development 
of realistic virtual subsystems that can be operated in a manner similar to the operation of a real 
mission system. In order to support mission operation, which includes command sequence 
composition, operation scheduling, system status reporting, science data production, and 
resource profiling. The operation behavior modeling and simulation must be tightly coupled 
with the physics of the space environment as well as spacecraft system performance. 

Capabilities 

• Operation feasibility analysis 

• Operation risk analysis 
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• Science-return probability analysis 

• Operation-centric performance requirement analysis (reverse design) 

• Automated science observation opportunity analysis. 

Technologies 

• Model-based analysis (automated design space exploration) 

• Time-based simulation 

• Real-time simulation 

• Operation behavior visualization 

• Operation environment simulation 

• Measurement simulation (instrument data product). 

Products 

Dynamics Simulator for Entry, Descent and Surface Landing (DSENDS) (JPL) 

DSENDS is a high-fidelity, multi-mission spacecraft simulator that models the multi-body, 
structural flexibility, environment, terrain/sensor interactions, and spacecraft devices during 
entry, descent and landing on planetary and small bodies. The specific use of DSENDS within 
the Mars Program is for the Smart Lander 2009 mission where it is augmented with high-fidelity 
aerodynamic subroutine libraries from NASA Langley. Mars-DSENDS will provide the real- 
time, end-to-end system simulation for the verification of flight software during the precision- 
landing and hazard-avoidance EDL phases of the Smart Lander mission. 

TRL: 4-6 


POC: J. (Bob) Balaram 
Ripples-MicroHelm (JPL) 

A PC-based scalable mission operation console for comprehensive spacecraft system state 
visualization. The visualization provides intelligent interpretation of critical subsystems 
including navigation, attitude control, telecommunication, and instruments. Three Micro-helm 
systems are currently in use performing: science scenario validation for Deep Space 1; real-time 
telemetry visualization for Mars Odyssey; and v irtual in-situ environment simulation for Mars 
Technology program. Future work includes integrated visualization of multiple spacecraft 
system states and interactive analysis of simulated vs. achieved system states. 

TRL: 5-7 

POC: Dr. Richard Weidner 
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ISHTAR develops synthetic sites and virtual instrument prototypes so that in-situ explorations 
can be virtually executed with high-fidelity measurement simulation. The site properties include 
geomorphology, material, soil mechanics, and aerodynamics. The instrument properties include 
signal integration, system noise, operation, and information derivation. ISHTAR provides virtual 
site and virtual instrument systems for DSENDS and ROAM, and various on-board processing 
tasks. The ISHTAR team also collaborates with the IS autonomy testbed team at ARC. 

TRL: 4-6 

POC: Meemong Lee 

Programmable Virtual Mission (PVM) (JPL) 

PVM develops (1) model -based science opportunity exploration, (2) Automated operation 
scenario generation, (3) Virtual environment-based scenario execution, and (4) comprehensive 
and real-time system state monitoring. The coupling of science requirement specification and 
mission system modeling enables concurrent engineering of mission system design and 
observation scenario design. PVM has been employed for miniature imaging camera and 
spectrometer observation planning for the Deep Space 1 mission. Future work includes interface 
with the mission formulation activity to assist science-return verification and validation. 

TRL: 5-6 

POC: Meemong Lee 

4.4.4 Rapid Prototyping and Testbed Architecture 

Modeling and simulation technology provides a cost-effective prototyping mechanism where a 
system can be virtually constructed and operated. Virtual prototypes and synthetic environments 
enable concurrent engineering of the mission lifecycle phases where integration and testing of a 
mission system can be performed in parallel with the mission system design and development. 
The virtual prototypes can be utilized to build a test-bed for verification and validation of flight 
software as well as end-to-end operation. 

Capabilities 

• Strategic feedback systems for mission design and engineering 

• Incremental software and hardware subsystem integration and testing 

• Plug-and-play system integration 

• Automated test scenario generation. 

Technologies 

• Hardware-in-the-loop simulation 

• Multi-level subsystem interface protocol 
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• Progressive system modeling and simulation. 

Products 

Avionics System Analysis Testbed (JPL) 

COTS-based avionics system testbed for rapid prototyping and analysis of avionics flight 
software. 

TRL: 3 

POC: Savio Chau 

Terrain Server and Rover FSW Analysis (JPL) 

Synthetic digital elevation model generation and distribution utilizing massively-parallel 
computation platform. The system is applied to analyze the performance of autonomous rover 
navigation flight software by executing the software in parallel over a synthetic terrain. The 
synthetic terrain can be also accessed via TCP/IP socket interface for other applications. 

TRL: 5 

POC: Dave Curkendall 
Simulated Science Scenario (JPL) 

This task provides an end-to-end science processing test-bed by integrating the mission data 
products acquired from the simulated environment with a real ground operation environment at 
JPL which includes downlink, calibration, analysis, and derived data product generation. The 
science scenario testbed is currently applied to validate the in-situ science exploration scenario of 
the MER project in conjunction with WITS and VIS. 


TRL: 5-7 

POC: Eric De Jong 

4.4.5 Human-based Process Modeling and Operator Training 

Modeling and simulation of human behavior and cognitive process introduces the human-centric 
perspectives to the mission lifecycle process for enhancing communication, coordination, and 
collaboration between multi-disciplinary teams as well as between humans and machines. The 
technology development efforts in this sub area address accurate modeling of human operators’ 
roles in future missions that engage multiple spacecraft systems with a high-level of autonomy so 
that the operability of a mission can be comprehensively analyzed. 

Capabilities 

• Team dynamics analysis 
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• Ground operation cost/risk analysis 

• Work-flow analysis 

• Human-centric data/information representation 

• Tactical feedback to operations team. 

Technologies 

• Human operator modeling 

• Work-flow modeling 

• Visualization 

• Sonification. 

Products 

Operator Function Model (OFM) (ARC) 

OFM includes a modeling methodology, a display design methodology based on the operator 
function model, and architecture that serves as the basis of operator aiding. OFM represents the 
supervisory control activities of operators responsible for the safety and effectiveness of complex 
dynamic systems. Operator aids have been developed and evaluated in the context of Georgia 
Tech Multi-Satellite Operations Control Center, a real-time interactive simulation of a NASA 
satellite control system. 

TRL: 5 

POC: Patricia M. Jones 
OF AN (ARC) 

OFAN is a formal, mathematically-based approach to the analysis of operator interaction with 
machines. A formal methodology for verification of interface correctness is used. Additionally, a 
formal procedure for display synthesis, whose objective is to provide a succinct and correct 
interface for the specified task, is briefly discussed. Special attention is placed on the analysis of 
pilots’ interaction with automated flight control systems onboard a modem commercial aircraft. 
Since the approaches used in OFAN are highly formal, current research focuses on how they can 
be integrated into standard engineering packages such as MATLAB. 

TRL: 5 

POC: Asaf Degani 
Brahms (ARC) 

Brahms is a multi-agent simulation tool for modeling the activities of teams, objects, documents, 
and computer systems. A Brahms model reveals how work actually gets done, especially how 
people interact with each other and with advanced technology. Workflow diagrams generated by 
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Brahms are the emergent product of local interactions between agents and systems, not pre- 
ordained, end-to-end paths. Applications of Brahms include system requirements analysis, 
instruction, design of software agents, and a workbench for analyzing and improving procedures, 
practices, and tools. 

TRL: 5 

POC: William J. Clancey 
APEX (ARC) 

APEX predicts human performance and human error using two component technologies. First, 
the model incorporates certain decision-making biases. Habit-capture errors are generally 
efficient, but prescribe incorrect behavior in some situations, leading to errors that are 
predictable (and therefore possibly avoidable). Second, the model incorporates a number of 
mechanisms that suppress reliance on fallible heuristics. For example, mental rehearsal is often 
used to retain critical information. Anything that prevents or interferes with mental rehearsal can 
therefore be a potential cause of error. We have demonstrated how this approach can be used to 
predict operational errors in the domains like spacecraft ground control. 

TRL: 3 

POC: Roger Remington 

Crew Activity Tracking System (CATS) (ARC) 

CATS predicts and interprets operator activities within a human-centered supervisory control 
framework. CATS is designed to predict activities based on anticipated mode usage; however, 
when interpreting operator actions, it can revise its expectations if the operator chooses an 
alternative, but valid, mode. This approach allows CATS to distinguish operator prerogative 
from human error. CATS has been validated in studies of human operators and controllers 
interacting with complex control systems and automated planning-scheduling systems. 

TRL: 5 

POC: Todd Callantine 

Super Resolution Display (ARC) 

Super-resolution is the process of combining multiple low-resolution images to form a higher- 
resolution one. While the super-resolution images are usually a huge improvement over the 
inputs, for large magnification factors the high frequencies are generally not reconstructed very 
well. Bayesian methods have been developed which overcome some of the limitations of other 
available methods. 

TRL: 3 

POC: Peter C. Cheeseman 
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ShowTime 2.0 (ARC) 

Available tools for careful evaluation of graphical displays (Video ToolBox, MatVis, 

Cinematica, CRS, VRG, HIPS, Morphonome, SuperLab, and many others) suffer from lack of 
generality, platform/language/display dependence, complexity, rapid obsolescence, fragile 
support, and inflexibility. The QuickTime COTS package offers many advantages in terms of 
very general format, display and platform independence, leveraging industry investments, easy 
transfer to papers and presentations, support for web demos and display-concept sharing. 
ShowTime leverages QuickTime by providing a simple calibrated QT movie player implemented 
as a Mathematica function: ShowTime (filename, options). 

TRL: 3 

POC: Andrew B. Watson 

4.4.6 Collaborative System Design and Operation Planning 

Virtual mission system enables collaboration among the distributed teams with cost-effective 
construction/replication of a mission system at distributed sites. This sub-area introduces 
technology development efforts for coordinating controls for geographically-distributed 
designers/investigators, updating and sharing design/plan information, and trading design options 
with interactive verification. 

Capabilities 

• Collaborative design environment 

• Collaborative operation planning environment 

• Automated operation planning and plan validation 

• Distributed remote control. 

Technologies 

• Centralized mission data warehousing 

• Operation environment simulation 

• Model-based analysis and model-space exploration 

• Internet portal. 

Products 

Web Interface for Tele-Science (WITS) ( JPL ) 

WITS is an Internet-based tool that enables scientists to fully participate in Mars lander and 
rover mission operations from their home institutions. WITS provides downlink data 
visualization and uplink plan generation. Distributed users can collaborate in visualizing 
downlink data, target selection, and plan generation. Simulation is provided to view predicted 
plan execution. 
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TRL: 6 

POC: Paul Backes 

Programmable Virtual Mission ( See Section 4.4.33 ) 

Next-Generation Remote Agent Planner (ARC) 

Mission operations activities have complex interactions and constraints among them, and any 
plan generated must satisfy all constraints and take all interactions into account. Building on the 
successful approach developed for the Remote Agent Planner, the new system provides all the 
key capabilities of the original planner, while adding functionality, improving performance and 
providing a modular and extensible implementation. The goal of this project is to develop a 
system that provides a basis for diverse applications. 

TRL: 6 

POC: Kanna Rajan 

Spacecraft Emergency Response ( GSFC) 

The objective is to use low-cost and easy-to-use tools to establish a collaborative environment 
between operators. The intent is to have a central access point for all the resources used in a 
collaborative mission-operations environment. The operators will be able to customize their view 
into the collaborative environment. Other features that will be added are a project summary page, 
discussion-board capability, transparent sharing of documents, and a common document 
repository. 


TRL: 5-6 


POC: Julie Breed 

Instrument Remote Control (IRC) (GSFC) 

IRC supports NASA’s mission by defining an adaptive framework that provides robust 
interactive and distributed control and monitoring of remote instruments. IRC will eventually 
enable trusted astronomers from around the world to easily access infrared instruments (e.g., 
telescopes, cameras, and spectrometers) located in remote, inhospitable environments, such as 
the South Pole, a high mountaintop, or an airborne observatory. 

TRL: 7 

POC: Troy Ames 

Science Expert Assistant (SEA) (GSFC) 

The goal of SEA is to improve mission operability for the Next Generation Space Telescope. 
This will be accomplished by reducing operations staffing and mission lifecycle cost, and 
providing superior proposal definition tools to users. The SEA will be evaluated against the 
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current proposal preparation process for the Hubble Space Telescope. In addition, operational 
spin-offs of SEA technology that occur along the way will add to the success of the effort. 

TRL: 7 

POC: Jeremy Jones 

Virtual System Design Environment (VSDE) (GSFC) 

VSDE is a collaborative design environment, providing geographically distributed design teams 
single point access to all product design data and tools via their desktop computers and Internet 
access. The VSDE is a portal and real-time access to: (a) A single knowledge repository for all 
product development data; (b) customizable user views and summaries for product data; (c) 
collaborative tools; (d) team and project management tools; and (e) design and engineering tools. 


TRL: 6-7 


POC: Johnny Medina 

Mission Data Warehousing and Mining ( GSFC) 

The goal of the study was to demonstrate the usability of data-mining technologies in a setting 
like the IMDC (Integrated Mission Design Center). Knowledge Management (KM) helps an 
organization to gain insight and understanding from its own experience. In the context of this 
study, KM can be defined as the systematic process of finding, selecting, organizing, distilling 
and presenting information in a way that improves IMDC’s staff comprehension in a specific 
area of the mission study. This task evaluated the use of Data-Mining techniques to address some 
of the IMDC knowledge management issues. 

TRL: 3-4 

POC: Walt Moleski, Johnny Medina 

4.5 Science Data Processing, Access, Analysis, and Knowledge Discovery 
4.5.1 Introduction 

The environment in which science is practiced is evolving, driven in part by rapid advances in 
detectors, space hardware, computing, networking, and software techniques. Astronomy and 
space science have traditionally been photon-starved pursuits, but are moving toward the likes of 
earth science with terabyte-sized data repositories. Scientists, often working together from 
geographically-distributed sites, are using data from multiple spacecraft, and the capabilities and 
complexities of the instruments are also increasing. Large-scale simulations are now 
incorporating observations, as well as driving experiment design. Space-bome and ground-based 
facilities are generating survey-scale datasets specifically designed to promote new discoveries 
for decades to come. Each new dataset increases the value of those previously acquired by 
enabling new queries and discoveries across them. Sky surveys on plates (POSS, POSS-2) have 
evolved through the all-sky survey missions such as UHURU and IRAS into a suite of new 
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projects that will map the sky in multiple ways (SDSS, GALEX, 2MASS, GSC-2, ROSAT and 
FIRST). The desire to seamlessly merge these large datasets across traditional boundaries of 
wavelength, spatial resolution and time pushes the limits of current capabilities. Increasingly, 
scientists depend on information technology tools to realize the potential of any of these missions 
and projects. 

Although advances in information technology are required simply to handle the data deluge, new 
software techniques can also drive science discovery. Among the examples of new science 
enabled by IT are: 

• Simulation of Earth-Sun connection 

— Understanding the ionosphere’s role in controlling the rate of reconnection where the 
earth's magnetic field meets the Sun’s 

— Modeling geomagnetic substorms 

— Modeling x-ray burst and eclipse observations of a variety of solar phenomena: 
prominences, the corona and the solar wind. 

• Solar System evolution 

— The discovery that the Solar System is unstable and that Mercury and/or Pluto may be 
ejected in the next billion years 

— Discovery of a short (5 Myr) Lyapunov exponent for the Earth’s orbit 

— Understanding that the earth’s moon was likely created by a large impact 

— A unified theory of cometary systems: the formation of the Oort cloud and Kuiper Belt as 
the inner solar system is cleansed of planetesimals. 

• Discovery of millisecond pulsars and planets orbiting pulsars 

• Processing of speckle interferograms to prove that there is a million solar mass black hole in 
our galaxy and that nearly all young stars are formed in binary systems 

• Image reconstruction and the rescue of HST science prior to refurbishment 

• Discovery of the mechanisms that distinguish the formation of elliptical and spiral galaxies 
as well as mechanisms that can transform spirals to ellipticals (cannabilism, merging and 
harassment) 

• Innovative missions — by either connecting a wide range of past and future activities or 
applying innovative new technologies for new mission paradigms. As examples: the rescue 
of HST science prior to COSTAR has lead to the notion of using very large imperfect 
mirrors; interpretation of data from constellations as well as the Internet in the sky concept 
are enabled by ubiquitous computing. 

• Mission rescue — infusion of information technology when surprises are encountered can 
enable or increase science return, such as with the use of image reconstruction for Hubble 
Space Telescope data prior to correction with COSTAR. 

• Planning and tuning — real-time, or near real-time, science-driven changes in observational 
strategy may be required. Increased onboard and ground-based processing capabilities will 
be required to dynamically schedule and coordinate multiple spacecraft. 
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• Connecting theory and observation for the deeper understanding — high quality simulations 
that assimilate observations are required to connect physical theories to the vast array of data 
on the current nonlinear state of the universe. 

• Finding the needle in the haystack — new missions are generating 10-20 TB of raw data with 
~1 TB of processed information. Only a minuscule fraction - less than 0.01% - of the objects 
in these databases will have been observed before, let alone identified, cataloged or 
investigated deeply. The value of new and legacy databases will depend on the new 
information system's ability to handle complex queries over multiple new and legacy 
archives. To this end, data mining, content-based search and semantic retrieval tools will be 
required. Interactive visualization tools for analysis, presentation and collaboration will be 
essential. 

• Distributed science — science collaborators require the capability to work from remote and 
distributed environments. Mobile computing technologies and effective collaboration 
frameworks are required. 

• Outreach — the modem digital libraries and simulation products will be key elements in 
communicating the excitement of NASA's science and research to the general public, the 
education community, as well as management and policy makers. 

The co-authors of this section have identified capabilities and technologies required for the 

process of scientific inquiry with the instruments and data produced in the evolving digital 

environment. We have identified representative examples of products under development. The 

search for examples uncovered few programs involving R&D for science: 

• Applied Information Systems Research Program (OSS), focused entirely on advanced 
information systems research to apply new developments in computer science and 
information technology to improve and enhance OSS science programs 

• Astrophysics Data Program (OSS), wherein the development of tools is occasionally a by- 
product 

• Earth and Space Science Project (Office of Earth Science), whose efforts are aimed at 
making teraFLOPS (trillion floating-point operations per second) computing systems an 
integral part of large-scale computing activities in the Earth and space sciences, focusing on 
facilities that allow the rapid porting and tuning of evolving applications to the local 
architecture and visualization tools capable of handling the data volumes associated with 
teraFLOPS systems and accessible from remote locations. 

• Advanced Information Systems Technologies (Office of Earth Science), among the 
objectives of AIST is to increase access to and utility of Earth science data. The program is 
designed to address technology needs for Earth science measurements, analysis and 
applications. 

• Earth Science Information Partners (Office of Earth Science), which funds the development 
of data and information products, technology and services for Earth science research and use 
by the broader community. 

• Intelligent Systems/Intelligent Data Understanding (OAT), supporting research and 
development for information technology solutions for on-board and ground-based 
information extract and knowledge discovery from science data. 
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• Cross-Enterprise Space Technology/Next Generation Infrastructure (OAT), supporting 
algorithm development for "computer intelligence methods" to facilitate and enhance 
computational analysis of physical phenomena. 

In addition to these programs, IT R&D for science applications is embedded in missions and 
science programs. Generally, however, applications developed for missions or science programs 
are developed to the tight specifications of the project and do not have broad applicability or 
potential for re-use. The following section is organized by broad application area, with specific 
examples highlighted where appropriate. 

N.B. The products mentioned in Section 4.5 do not represent a comprehensive list of all ongoing 
efforts across the Agency involving information technology research and development to enable 
science discovery. Compilation of such a list is beyond the scope of this study. 

4.5.2 Spacecraft and Data: Coordination and Integration 

Integration of information from multiple platforms has been recognized as an important need in 
space science for a long time. With the expected growth in space science information and the 
broadening of the user community, this need will become more pronounced. Much of the effort 
in facilitating integration has concentrated on developing common data formats, such as FITS, 
CDF and HDF. While products of these efforts facilitate integration of datasets from different 
platforms if they are written in the same format, their emphasis is on form, rather than on the 
content. Ability to describe content so that human researchers and software agents can discover 
relationships, and determine whether information available from a particular platform is 
potentially useful for validating current understanding should be an essential component of the 
space science information infrastructure. Content-based search tools are discussed in Section 
4.5.5. 

Included among the primary research and development challenges for cross-platform integration 
are: 

• Development of common vocabularies for space science domains 

• Specification of machine-interpretable definitions of basic concepts in the space science 
domains and relations among the concepts 

• Software agents that understand these relationships and thus can discover information 
relevant to a concept, theory or phenomenon 

• Software mediators that enable translation of existing information to formal domain 
vocabulary. 

Coordinated observation of an object or a phenomenon by making related observations from 
instruments on the same or different spacecraft helps increase science return for NASA 
investment. Coordinated observation poses the challenges listed above in the knowledge and 
technology domains, and also requires meeting the following challenges: 

• Assessing feasibility for configuring instruments and spacecraft 
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• Scheduling - onboard recognition of significant events of potential interest to other 
instruments and spacecraft 

• Timely communication among participating systems. 

Progress in developing ontologies for the various disciplines involved in space science enterprise 
will help lower life-cycle cost of missions through increased automation as well as improved 
communication among all participants in space science enterprise - scientists, engineers, 
programmers. Improved knowledge discovery will help not only scientists, but also students and 
the public. 

4.5.3 Large-Scale Active Data Repositories 

The purpose of this section is to address some of the challenges associated with managing large 
quantities of data that are anticipated to be collected, archived and distributed to users, identify 
capabilities required and examples of activities currently providing some of the capabilities, and 
identify areas needing further research. The details are different between the Earth-Science and 
Space-Science missions; however, from the point of view of information science and technology, 
there are many similarities in challenges, capabilities needed and the research required. Many of 
the challenges associated with large data volumes are currently being addressed in support of the 
Earth-Science Enterprise. Hence, it would be useful to coordinate the efforts between ESE and 
SSE in this area. 

The main challenges in this area are: 

• Large volumes and high data rate 

• Large number of granules 

• Diversity of providers 

• Diversity of users 

• Long-term data preservation. 

Large Volumes and High Data Rate 

The volume of NASA mission data has been growing very significantly over the past few years. 
The EOS mission is currently archiving over 1 TB of data per day and is expected to archive 
about 2 TB per day when all the spacecraft are in operation. Space science missions are 
expected to produce and archive increasing volumes of data as well. The space science data 
volumes today are in the range of a few tens of terabytes. These are expected to grow rapidly 
over the next decade. For example, the contributors to the National Virtual Observatory are 
expected to generate petabytes per year, and the Large Synoptic Survey Telescope is expected to 
produce over 10 PB/year, starting in 2008. Ongoing activities relevant to addressing the 
challenges of large volumes and high data rates include: 

• Automation - robotic tape silos 

• Disk-based archives as and when they become economically and technically viable 

• Migration to new technologies as they become commercially developed and operational 
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• Adaptive/Intelligent Archives - monitoring usage patterns, anticipating demand for specific 
sequences of granules and preparing ahead to provide better response; providing 
serendipitous access; creation of indexes. 

Large Number of Granules 

The data repositories need to address individually and keep track of thousands of data sets (or 
collections) and millions of granules - files , gro ups of files or other types of inventoried objects. 
(For example, the EOS mission currently produces over 4 million granules per year and will be 
producing over 7 million granules per year when all of its spacecraft are operating.) These 
granules vary in size and coverage depending on the mission requirements and the conveniences 
of the data producers. Ongoing activities relevant to addressing the challenges in this area 
include: 

• Adherence to standards and provision of mechanisms to evolve standards 

• Rich set of metadata - various levels of indexes to data 

• Providing for updates to metadata 

• Adaptive/intelligent archives - monitoring usage patterns, anticipating demand for specific 
sequences of granules and preparing ahead to provide better response; providing 
serendipitous access; creation of indexes. 

Diversity of Providers 

The number and type of data providers in both Earth and space sciences is large and expected to 
continue to grow. Providers will be from different scientific disciplines and may have varying 
levels and types of responsibility. They range from government organizations with 
responsibility to serve all comers and non-profit organizations with focused discipline 
responsibilities. Interface standards, different levels and types of interoperability, and 
corresponding protocols are therefore required for data, metadata, messages, etc., to facilitate 
exchanges among groups of providers or providers and users. It is important to devise 
mechanisms to identify which providers own the data sets needed by the users. Ongoing 
activities relevant to addressing the challenges in this area include: 

• Distributed systems’ interoperability 

• Adherence to standards and provision of mechanisms to evolve standards 

• Minimal set of standards and interface agreements 

• Translation tools 

• Rich set of metadata - various levels of indexes to data 

• Providing for updates to metadata. 

Diversity of Users 

Except in the case of data repositories with a rather narrow focus and a well-established 
applications area, it is difficult to predict the demand and usage patterns for the data. New 
applications and types of analysis are discovered frequently, and new communities of users tend 
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to grow. Correspondingly, the access patterns vary significantly. Users may access just the 
metadata to find out about the characteristics of a data collection, how the data were obtained, 
algorithms used for processing, etc. Users may use metadata for locating data that cover specific 
spatial regions or intervals of time. Prior to ordering, accessing or acquiring the data, users may 
want to view (or browse) the data. The users may then order specific granules from the 
repositories. Depending on the size of the granules, the data can be downloaded via the Internet 
or shipped on media, such as CD-ROMs or tapes. Some users may be interested in obtaining 
entire collections of data pertaining to specific regions or application disciplines, in order to 
provide value-added services to other users. A common user requirement, especially on image 
data collections where the granules are large in size (say > 1 GB each) is to obtain subsets of 
images that meet their specifications. Subsetting is just one example of methods of reducing the 
amount of data to be transmitted to meet the user’s needs more closely than sending entire 
granules or collections of data. Clearly, the data repository performs some computations while 
extracting subsets. The computations may involve just the metadata or the image granules 
themselves. This idea can be extended to allow more general computations at the data 
repository. For example, users may be permitted to submit data-mining algorithms to the archive 
and obtain the resulting information (rather than data). Thus, users’ requirements may range 
from access to large quantities of data, to just the relevant digested information from the large 
distributed data holdings at multiple repositories. Ongoing activities relevant to addressing the 
challenges in this area include: 

• Adaptive/intelligent archives - monitoring usage patterns, anticipating demand for specific 
sequences of granules and preparing ahead to provide better response; providing 
serendipitous access; creation of indexes 

• Intelligent assistants - e.g., agents that crawl the repositories and identify interesting data 

• Variety of data access mechanisms - networks and media 

• Access and display tools 

• Adherence to standards and provision of mechanisms to evolve standards 

• Rich set of metadata - various levels of indexes to data 

• Providing for updates to metadata 

• Providing access to documentation, ancillary data, algorithms, etc. 

• Supporting computational facilities at data repositories - distributed data mining; content- 
based searches 

• Distributed systems’ interoperability 

• Data pools - staging areas that maintain most frequently used data to facilitate easy access to 
frequently requested data 

• Value-added providers - specialized sub-repositories to meet sub-community needs 

Long-Term Data Preservation 

Most of NASA’s satellite-acquired data are expensive to obtain. Any data from the past that are 
lost can never be reacquired. These considerations dictate several storage requirements. At a 
minimum, raw data and all ancillary data, documentation, and software needed to generate 
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higher levels of products must be permanently stored. Any data products that require special 
expertise and quality control to generate should be considered for permanent storage. Just as 
important is the preservation of the metadata and search tools, to ensure that the data of interest 
can still be located several years in the future. The media must ensure long-term survival of data 
or, alternatively, data need to be migrated sufficiently frequently to newer media. Quality checks 
should be performed to ensure data integrity. Technology upgrades need to be made to ensure 
that the data continue to be readable. Ongoing activities relevant to addressing the challenges in 
this area include: 

• Migration to new technologies as they become commercially developed and operational 

• Long-lived media 

• Periodic migration of data to avoid loss 

• Maintenance of documentation, ancillary data, algorithms, etc. 

Examples of Relevant Current IT Work 

• The Astronomical Data Center at the National Space Science Data Center plays a lead role in 
the development of XML (extensible Markup Language) applications to address NASA’s 
needs in astrophysics data management. For example, the ADC developed XML-based 
tools for the automated ingestion of catalogs and tables and for facilitating the search and 
retrieval of these data. 

• NASA data centers and information providers will play a key role in the definition of 
metadata standards and data models for the development of a National Virtual Observatory. 
The NASA centers have already established leadership in this area, e.g., with the 
Astrobrowse data discovery tool and the initial work on profiles earned out under the ISAIA 
project, funded through OSS via the Applied Information Systems Research program. 

• EOSDIS - presently handling over 1 TB of data per day in a distributed set of data centers; 
maintaining over 1450 data sets; distributing to a diverse and growing community of tens of 
thousands of users. 

• Global Change Master Directory - >8500 descriptions of data sets in various disciplines. 
Recently added tools and services to the directory. Participation in national and international 
groups promoting metadata standards. Making it simpler for providers to input directory 
entries for their datasets using a shorter directory interchange format (DIF) called skinny 
DIF. 

• EOS Data Gateway - interoperability at inventory level achieved among 9 data centers in the 
U.S. and several international data centers - provide access to data from EOS and many other 
Earth Science missions, field experiments, etc. 

• EOS Clearing House - being developed as a brokering service to enable development of 
metadata search clients specific to user sub-communities. This is done by building a flexible 
clearing-house and service-broker infrastructure based on XML and e-commerce concepts. 

• Distributed Oceanographic Data System - Several institutions led by University of Rhode 
Island and MIT developing the system to provide access to data on any network accessible 
DODS server. Enables a wide network of distributed data providers. Simplifies data 
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providers’ effort by not constraining content or format of semantic metadata. Users can 
access data regardless of the format in which data are stored. 

• Earth Science Information Partners (ESIP) Federation - an experiment independent of the 
“big” EOSDIS system for developing a set of with governance structure and interoperability 
protocols to facilitate a heterogeneous data provider environment. 

4.5.4 Large Scale Modeling and Simulation 

Important new techniques are under development for the simulation of as trophy sic al, 
geophysical and space weather phenomenon. Such simulations produce detailed solutions to 
highly-complex problems in stellar evolution, galactic dynamics, numerical cosmology, space 
physics, geodynamics and many other fields. These problems either have enormous complexity 
due to many simultaneous interacting systems or have fundamentally nonlinear processes 
without analytic solutions. Depending upon the size of the problem, either high-performance 
workstations or massively-parallel supercomputers are required. 

It is becoming readily apparent that any data set in astronomy can only be fully understood and 
interpreted in the broader context of its dynamical environment. This is due to the intrinsic 
nonlinearity of dynamics within which any specific astronomical system is studied, i.e. in 
nonlinear dynamics, all scales interact with one another, although on different time scales. This 
issue is in fact one of the principal challenges to understanding the formation of large-scale 
structure, and subsequent formation of structure on smaller scales, including star formation. The 
dynamic range considered both theoretically and empirically is staggering - literally ranging 
from the causal horizon of the entire universe to solar system scales. 

In order to test theoretical understanding exemplified through the simulations, large data sets are 
needed at many different wavelengths. The theoretical goal is not to predict the exact structure 
observed in our universe, but to predict the morphological patterns, along with other properties. 
In other words, a statistical characterization of simulations and observations is needed to 
facilitate a comparison of theory and experiment. 

An increasing number of such examples is arising in astronomy, particularly as current and near- 
future experiments probe physical conditions at unprecedented spatial resolutions and sky 
coverage. As increasing numbers of observed maps at various frequencies become available, a 
gallery of events is captured, each providing clues to the possible physical mechanism at work 
generating the observed structure. Testing a theory explaining the observed morphological 
structure in observed maps is essentially a problem of quantifying the statistical similarity 
between simulations and the data. 

An example of such a problem is the analysis of the Cosmic Microwave Background (CMB) 
from future satellite missions. The CMB provides a direct glimpse at the statistical properties of 
the initial conditions of the structure formation problem. The prized information locked away in 
the data to be returned is the power spectrum of the CMB, providing a statistical characterization 
of the data to be compared with expectations within various cosmological models. Standing in 
the way of a direct observation of the CMB power spectrum are various galactic and extra- 
galactic foregrounds, and instrumental noise. A direct computation of the optimal power 
spectrum estimate along with its errors is a computationally prohibitive task for large, all sky 
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maps (an 0(N 3 ) computation). The fundamental problem making CMB analysis such a 
computationally intensive problem is that the underlying signal, which is an example of a 
rotationally invariant random field, is observed with a non-stationary noise process. 

Far from being a specific problem for CMB analysis, observations of large areas of the sky will 
typically involve non-stationary Gaussian additive noise at each point on the sky, making the 
extraction of statistical characterization of the underlying physical process complicated. In 
addition, the presence of foregrounds is also a common problem - the problem is similar to 
isolating a conversation at a party in the midst of many other conversation^. The solution to the 
analysis of data as observed with non-stationary noise in the presence of foregrounds is required 
in order to compare observations with the expectations from theory. Without a computational 
framework for solving this inference problem, there will be perpetually a gap in what is learned 
from experiments and the information that could be extracted. 

Cosmic Microwave Background Data Analysis Tools (COMBAT), funded by OSS through 
Applied Information Systems Research program, seeks to address the problems inherent in 
analyzing the very massive datasets being generated by the current generation of ground-based, 
balloon-borne and satellite CMB experiments. The tools to date include: 

• FORECAST - an interactive web-based tool for generating maps of known foreground 
sources at any given frequency, used for planning partial-sky observing strategies for balloon 
or ground based experiments, enabling them to select survey areas with low foreground 
emission 

• WOMBAT - the wavelength-oriented microwave background analysis tool used to test the 
ability of particular experiments and/or data analysis methodologies to discriminate between 
different sources 

• MADCAP - the microwave dataset computational analysis package, used to extract the 
maximum likelihood sky-map and angular power spectrum from real observations of the 
CMB (including both correlated noise and other parasitic signals). 

A recent example of high-performance computational space science is the planetary 
atmospheres, ionospheres and magnetospheres project at the University of Michigan (PI: M. 
Combi), funded by OSS through the Applied Information Systems Research Program. This 
project uses a 3D particle code to study the complex interaction of co-rotating magnetospheric 
flows This code is also being applied to study particle precipitation from the Earth’s 
magnetosphere in the ionosphere and thermosphere and Jupiter’s interaction with Io. A 
kinetic/MHD hybrid model from this project can be applied to a wide variety of atmospheric and 
space science problems. Advances in modem parallel computers mean this type of calculation 
has become practical for performing a range of simulations important to upper atmospheric, 
ionospheric and magnetospheric Earth and planetary problems. 

Another example, also funded by OSS through the Applied Information Systems Research 
Program, is the space weather project lead by T. Gombosi at the University of Michigan, where a 
recently developed, highly-parallelized adaptive mesh refinement scheme is used to produce 
high-resolution upwind finite-volume formulation and explicit multi-stage time stepping to solve 
the time-dependent MHD equations in conservation form. This research will provide new insight 
into the effective design of parallel implicit techniques for the solution of nonlinear systems and 
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should have impact in several areas of high-performance scientific computing. In addition, the 
resulting method should represent a significant improvement over the current generation of space 
plasma simulation tools, and thereby permit the study of a much wider class of problems. 

Applied Informations Systems Research also funds a team at the University of Washington that 
has adapted a massively-parallel, spatially- and temporally-adaptive cosmology code to Solar 
System dynamics. The code calculates the gravity and collisions among particles using a tree 
algorithm that scales well with the number of particles. It is now used to calculate colliding 
planetesimal simulations with millions of particles. This has advanced the state-of-the-art by two 
orders of magnitude in particle number. For the first time, full disk simulations of the formation 
of the terrestrial planets are being performed. Such high-dynamic-range simulations are 
necessary for making predictions about the amount of radial migration of the planetesimals, the 
origins of small bodies, and the proper interpretation of data from missions that determine the 
composition of individual objects such as GENESIS, CONTOUR, Rosetta, and NEAR. The 
application of a cosmology code to Solar System physics represents a first step in creating a 
modular, but massively-parallel, framework for the simulation and analysis of very large 
unstructured data sets. As well as cosmology and planetesimals, the code is being used to 
simulate astrophysical gas dynamics, asteroid collisions and granular dynamics. Such an 
adaptive, massively-parallel framework will also be necessary for any non-local analysis of the 
large amount of high-dynamic-range data such as that obtained from missions contributing to the 
National Virtual Observatory and the Earth Observing System. 

4.5.5 Content-Based Search Tools 

• Semantic understanding (text) 

• Knowledge discovery (data mining, feature recognition, event detection). 

4.5.6 Interactive Visualization 

Data visualization is a discipline-driven activity. Interactive visualization applications exist in 
many fields, such as: business, engineering, medical anatomy, high-energy physics, underwater 
observations, fluid dynamics. Earth remote sensing, space science, and the entertainment 
industry. This section focuses on the application of interactive visualization to space-science 
observations, which is a subset of the general industry category of scientific visualization. The 
goal of scientific visualization is to create new representations of models, measurements, 
instruments, and processes. Scientists need visualization tools that enable them to create and 
interact with these representations in real-time, using distributed immersive desktop 
environments. The new representations should be designed to aid scientists in their efforts to: (1) 
make new discoveries, (2) better understand fundamental processes, and (3) communicate 
scientific results to their colleagues and the community. 

Computer processing, display hardware, and Hollywood special-effects software has advanced 
rapidly in the last decade, enabling investigators to produce remarkable individual images and 
scientific animations for a wide variety of topics. Unfortunately, the state of the art in the 
development of intelligent science interfaces and interactive science tools has lagged far behind 
the development of tools for the entertainment industry. Scientists, unlike “gamers”, do not have 
the opportunity to directly control and view the fundamental data representation process in real 
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time. Of necessity they team with animators and graphic artists, to create even moderately- 
complex visualization products. They often must wait hours, days, or even weeks to see their 
results. 

With the increasing complexity of scientific instrumentation and the resulting multi-dimensional 
datasets, scientific research and analysis will benefit more and more from the ability to 
interactively visualize large, multi-spectral datasets in real-time. Science return will be enhanced 
from interactive visualization incorporated into each step of the discovery process. Included 
among the capabilities that will be enhanced by advances in interactive visualization 
technologies are: 

• Exploration of scientific concepts in the proposal phase 

• Design and development of instruments and subsequent operations (including remote 
control) 

• Organization and search of multi-resolution data bases 

• Data processing, e.g., display of the processing pipeline 

• Classification, segmentation and pattern discovery in data 

• Comparison of models to measurements and visualizing physical processes. 

Ongoing efforts in information technology to address the required capabilities include: 

• Simulation, knowledge engineering, display technology 

• Modeling languages 

• Search engines, intelligent agents, object-oriented database structures 

• Image processing 

• Pattern recognition, neural networks, artificial intelligence, feature tracking 

• Ray tracing, procedural rendering, particle systems 

• Tele-science, remote video control, multi-screen displays, multi-casting. 

Example interactive vizualization products are shown in Table 4-2. 


Table 4-2. Interactive Vizualization Products 


ID 

Product 

POC 

Center 

SVT 

Science Visualization Test-bed 

Shigeru Suzuki 

JPL 

SOAP 

Satellite Orbit Analysis Program 

Chuck Acton 

JPL 

MNV 

Mars Net Viewer 

Paul M. Andres 

JPL 

PIA 

Planetary Image Atlas 

Susan K. Lavoie 

JPL 

BAT 

Beowulf Architecture Test-bed 

Myche McAuley 

JPL 

AFT 

Automatic Feature Tracker 

Jean J. Lorre 

JPL 

GCM-M 

Global Circulation Model - Mars 

Robert Haberle 

ARC 

GCM-J 

Global Circulation Model - Jupiter 

Andrew P. Ingersoll 

Caltech 
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Science Visualization Testbed (SVT) (JPL) 

The Solar System Visualization project (SSV) and the Science Visualization Testbed (SVT) are 
illustrative examples. The SSV- SVT is a platform-independent stereo HDTV visualization test- 
bed containing the latest state-of-the-art visualization hardware and software. The hardware 
includes: Stereo HDTV real-time compressors and de-compressors, disks, tape recorders, 
monitors and large -screen projectors; nonlinear editors; 10-terabyte RAID; 60-node Beowulf 
cluster, science-visualization workstations; DVD writers, and a 100-node 24-Gbps fiber-optic 
network. The SSV-SVT is installed in JPL’s Digital Image Animation Laboratory. The SSV- 
SVT is used to: 

• Apply information-systems technology to solve space-science problems 

• Adapt commercial software to solve space-science problems 

• Modify legacy software to operate on new computer systems 

• Test new information-systems concepts, using representative space-science problems and 
data 

• Develop, demonstrate and validate technology for virtual presence in space 

• Adapt HDTV and IMAX technologies to visualize space science results 

• Create new visualization and analysis products for space science missions. 

The SSV-SVT primary focus is to conduct visualization research in: 

• Dynamic process models 

• Remotely sensed and in situ observations 

• Observation based models and simulations 

• Mission plans and instrument designs 

• Science collaboration 

• Instrument operations 

• Virtual reality. 


v 
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An important goal of the SSV-SVT research is to increase NASA’s science visualization display, 
animation, recording, archiving, and video-distribution capability from its current NTSC 
resolution (640 samples x 480 lines x 8 bits of color), to HDTV resolution (1920 samples x 1080 
lines x 24 bits of color). 

Code SR SIS Program, TRL= 3-4; expected to achieve TRL=6 in 2004. 

POC: Shigeru Suzuki 

Satellite Orbit Analysis Program (SOAP) (JPL) 

SOAP is an interactive simulation that employs three-dimensional animation to display the 
relative motions of satellites, ground stations, aircraft, ships, the Sun and the Moon. The 
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positions and velocities of these moving platforms are calculated from user-defined initial 
conditions using embedded propagation algorithms. Users can build coordinate system 
hierarchies, which are then used to construct three-dimensional views, orient sensors, and define 
spacecraft altitudes. SOAP runs as a native application under Windows 95, 98 and NT. SOAP 
also runs on Power Macintosh computers and Sun Sparcstations running Open Windows or 
OSF/Motif. SOAP supports a rich set of user-defined animated graphical and textual displays. 
Three-dimensional perspective projections and parameterized rectangular projections can be 
built using platform positions and user-defined coordinate systems. These projections can 
contain detailed Earth and star maps with options for user-defined features. Satellite orbit 
trajectories, ground traces. Earth footprints, and sensor field of view (FOV) volumes may also be 
displayed. Many options exist for defining animated time-based variable plots and instantaneous 
data displays. Graphical output can be generated in a variety of formats. A report generation 
feature supports text file output of tabular simulation data in spreadsheet format. Visibility 
relationships between simulation objects are obtained using sensor FOV volumes having user- 
specified geometric constraints. A radio frequency communications model is also provided. 
Supported FOV geometries include sections of sphere, sections of cones, and polygonal solids. 
Each FOV volume is assigned a user-defined coordinate system for pointing and orientation and 
may be assigned to multiple platforms. Earth occlusion and other constraints may be taken into 
account when computing visibility status. Links and cues are used to indicate when visibility 
conditions are met. 

POC: Charles Acton 

Autonomous Feature Identification (AFT) and Data Compression (JPL) 

Identifying common features in multiple images of surfaces and atmospheres is the most 
fundamental problem in executing autonomous planetary missions. The features are required to 
identify targets, determine spacecraft position, measure displacements, and compute wind 
velocity. The goal of the Autonomous Feature Identification and Data Compression task is to 
establish an operational Windows Interface for Nominal Displacement Selection (WINDS). 
WINDS will provide JPL with a feature identification, displacement measurement, velocity 
measurement, terrain analysis, atmospheric analysis and terrain/atmospheric animation 
capability. This capability will be implemented in the Multi-mission Image Processing 
Laboratory - Digital Image Animation Laboratory. WINDS will provide a test bed for planning 
autonomous missions. It will enable us to design, develop, test and validate algorithms intended 
for on-board implementation using the latest mission results and science models. WINDS will 
provide a fundamental atmospheric science analysis and visualization capability for use by the 
planetary science community, mission planners and mission operations personnel. Current 
systems use a human operator to identify features. This is expensive and time consuming, and 
therefore allows scientists and engineers to examine only a handful of the thousands of 
atmospheric images that exist. We plan to automate this process using a new program developed 
for correlating features in a series of atmospheric images. 

SSV-SVT, Code SR SIS Program, TRL= 3-4; expected to achieve TRL=6 in 2004. 

POC: Jean J. Lorre 
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VIZ (ARC) 

VIZ is a software application that handles 3-D visualization and user interaction with an 
environment. It comes with a set of utilities including science analysis tools, planning tools for 
robotic control, and various utilities for telemetry/sequence replay and simulation display. It also 
provides animation capabilities. Viz is the latest version of the Autonomy and Robotics Area’s 
developments of Virtual Environment for Vehicle Interfaces. Viz employs a client-server based 
architecture to allow the developer to rapidly tailor Viz to specific applications. It is designed to 
run as a rendering server to which clients connect in order to manipulate to the 3-D environment. 
In this way, the core of the 3-D functionality is isolated from other application specific issues. 
The default user interface for Viz exposes the application’s basic functionality in an easy-to-use 
manner. The interface is divided into three main windows: the 3-D visualization window, the 
toolset window, and the display window. The 3-D visualization window renders the 
environment. It includes any 3-D object you load into Viz, such as photo-realistic terrain models 
and CAD models of the robotic system. Using the mouse in this window, you can navigate in the 
3-D environment, look around, zoom onto a feature, popup different views, inspect the 
wireframe of the terrain, and perform operations on the environment or interact with the objects. 
On Silicon Graphics Octane and Onyx workstation. Viz can display the scene in stereo-mode, to 
give a 3D effect with the Stereographies glasses. The Toolset window allows you to access all 
the tools and functions of the Viz software package by clicking on the appropriate button. The 
Display window displays status information from the application to the user. 

POC: Lawrence Edwards 

The Web Interface for Telescience (WITS) ( JPL ) 

WITS is an Internet-based tool that enables members of geographically-distributed science teams 
to participate in daily planetary lander and rover mission planning. WITS enables the viewing of 
down-linked images and results in various ways, terrain feature measurement and annotation, 
and the planning of daily mission activities. WITS is written in the Java language and is 
accessible by mission scientists and the general public via a Web browser. The public can use 
WITS to plan and simulate their own rover missions. WITS was used during the 1997 Mars 
Pathfinder mission primarily for public outreach and was evaluated as a science operations tool 
at JPL. WITS capabilities are being combined with rover control workstation capabilities to 
create an integrated tool for Mars Exploration Rover (MER) operations. Two MER rovers will 
land on Mars in January 2004. 

4.5.7 Distributed Collaboration 

The changes in technology are not only influencing the amount of data acquired, or the way data 
are analyzed, but they are also affecting the environment in which scientists are working. The 
world-wide internet connectivity makes it possible for scientists to communicate with each other 
easily. This ease of communication and the developments in complex instrumentation and 
theoretical models promote large collaborative efforts. At present the communication among the 
collaboration members is mostly via e-mail, ftp and voice-mail. No collaborative tools exist to 
effectively and intuitively facilitate the scientists in conducting their scientific investigations 
seamlessly in a distributed environment. We need a tool, in the spirit of Microsoft’s Netmeeting, 
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that will give us the ability to communicate, but with the addition of data visualization and 
manipulation capabilities. 

Science proposals are also developed in a distributed environment, and e-mail is at present the 
primary means of communicating ideas and changes to the proposal. E-mail is asynchronous, 
however, and a proposal preparation tool allowing simultaneous, multi-user access would be 
much more efficient. 

Society as a whole is now becoming more and more mobile, and this change is also seen in the 
scientific community. Scientists are always on the move conducting their observations, going for 
meetings, etc. Simultaneously, observatories are changing operations strategy so that they can 
make opportunistic science possible. This implies that scientists have to interact and respond 
with observatory staff on short time scales. The present strategy is to respond via telephone and 
e-mail with minimal data available for decision making. The science community is not yet 
taking advantage of the new developments and capabilities of mobile devices, such as PDAs. 
Strategies and applications that will permit rudimentary analysis using PDAs should be 
developed so that scientists can respond in near real time independent of location. 

Due to limited funding, observatories must work with smaller and smaller operations staff, even 
as instrument complexities and data volumes are increasing. We need to consider developments 
in computer science to generate tools that can provide intelligent support to scientists for science 
goal monitoring during operations. This is an important step before we can consider autonomous 
science event detection, which is considered strategically critical for future missions. 

Certain observatory operations could be farmed out to the science community, thus reducing 
science operations costs. For example, detector calibration could be done by the scientists in the 
community, but tools are required that would make it easy for the results of such work to be 
integrated back into the main calibration strategy. This is easy in an environment where there are 
only a few people involved, but complex instruments need many more people and the 
coordination effort becomes an insurmountable impediment without intelligent tools for 
collaboration. 

With the advent of Java, the first steps in developing collaborative proposal preparation tools 
have been taken. Two examples are the scientist’s expert assistant and the visual observation 
layout tool. These tools are very rudimentary. 

The scientist’s expert assistant (SEA) comprises a set of software tools to guide scientists in 
developing valid observing programs, such as: 

• A tool to visualize the field-of-view (visual target tuner) 

• An exposure time calculator 

• A tool that manages collections of observations 

• A tool for target/telescope/instrument/detector simulations. 

SEA can be leveraged by several user groups: 
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• For observers - to effectively determine how various parameters affect their data and their 
scientific objectives. 

— Phase 0 tools for initial framing of observations 

— Validate proposed observations ahead of time 

— New complex instruments are driving need for newer visualization tools 

• For observatory staff - to characterize and understand the telescope/ instrument/ detectors, 
facilitating better analysis of instruments with fewer calibrations. 

• For the archive user - to understand the quality and limitations of an archival image. 
Innovations incorporated in SEA include: 

• Single integrated suite of tools that can be used from observation planning (idea) to 
observation execution (data) 

• Pluggable design allowing multiple disparate models and tools to be integrated into the SEA 
framework 

• Support for multiple observatories and instruments 

• New visualizations of data, including spectroscopic data 

• Intuitive user interface and tools that are configurable by the end-user 

• Generic, flexible data simulation capability that can be dynamically controlled by the end 
user interactively 

• Integration and comparison of simulated images with historical archive images. 

VOLT is also a Java application like SEA that helps automate the planning of observations, 
especially multi-wavelength observations by multiple observatories. This tool is developed to 
increase the scheduling probability of all observations. It can be used as a standalone tool or in 
tandem with SEA for a complete observation planning tools set. Volt has the same objectives as 
SEA. VOLT has been funded by the SOMO Technology Development Program. This tool can 
also be leveraged by observatory staff to help mission schedulers coordinate observations among 
various observatories. 

4.5.8 Communication with Diverse Audiences 

Knowledge management tools that permit communication among team members and 
coordination of documents (production, publishing and archiving) are commercially available. 
Few science organizations take advantage of these powerful tools. Such software is particularly 
useful for coordinating science results to report to management and to provide material for 
manipulation for public consumption. As an example, both managers and public affairs 
coordinators could have access to a document management system where scientists routinely 
post highlights with figures and images. While a manager may use the material in a different 
way than the public affairs coordinator, the scientist need only make the material available once; 
s/he needn’t recreate the wheel each time there is a need-it-by-yesterday request for information. 
Private industry learned this lesson years ago: information technology has enabled businesses to 
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provide direct access to information by the consumer of the information, thus eliminating costs 
incurred in the preparation of reports by someone other than the end-consumer. 

An area that could greatly benefit from further development of information technology tools and 
applications, however, is the communication of science to learners in both the formal and 
informal education communities. Advances in information technology have offered 
unprecedented opportunity for educators and learners to access scientific data and information, 
as well as expanding opportunities for participation in scientific investigations. IS has supported 
several technology initiatives to the furthering of formal education and lifelong learning, and has 
played a key role in supporting pioneering web-based educational applications. 

Early in the development of the web, IS funded activities took advantage of the flexibility of the 
medium to provide up-to-date data and information with a timeliness that is simply impossible 
with textbooks. Such web-based educational sites capture student fascination with NASA’s 
mission by providing information on current explorations. For example. Rice University, funded 
through HPCC, developed a digital museum by constructing interactive displays of real-time 
earth and space-science data. This interactive exhibit debuted at the Houston Museum of Natural 
Science and is now generally available for museums, schools, and individuals around the 
country. Similarly, the Lockheed Martin Solar and Astrophysics Laboratory, also funded through 
HPCC, offers the latest solar images, movies, science nuggets and variety of hands-on learning 
activities at the Yohkoh Public Outreach Project. These sites offer educational experiences that 
cannot be provided through traditional media. 

NASA has also supported projects providing resources specifically for teachers to facilitate 
hands-on and minds-on inquiry-based learning. The Smithsonian Astrophysical Observatory’s 
award-winning Everyday Classroom Tools, is an inquiry-based science curriculum for 
kindergarten through sixth grade (HPCC funded). This site provides end-to-end resources for 
teachers, including background materials to bring the teachers up to speed, carefully-developed 
Threads of Inquiry (lesson plans), and turn-key activities (Eyes on the Sky, Feet on the Ground: 
Activities for Students). Such full-service web sites for teachers are particularly effective, given 
the large number of teachers who teach science but have little or no science training. 

Perhaps the most powerful impact to learning delivered by advances in information technology is 
the ability to remotely participate in scientific investigations. The Telescopes in Education (TEE) 
project at JPL, funded in part through OSS and Code FE, has been wildly successful in engaging 
the K-12 education community in real-time, hands-on, interactive astronomy activities. Hundreds 
of schools in the US, Australia, Canada, England, and Japan have participated in the TIE project, 
remotely controlling the 24-inch telescope at the Mount Wilson Observatory from their 
classrooms. The demand became so overwhelming that one telescope was not enough, and 24 
other telescopes have been (or are now in the process of being) outfitted for remote use as TEE 
affiliates. 

A second powerful example of remote participation approaches the subject from a different 
angle: at Carnegie Mellon University, the EventScope project, funded through Code FE, has 
developed a virtual-reality viewer integrated in a web-browser for remote exploration of NASA 
datasets. They include curriculum modules (e.g. for their Mars exploration, an inquiry-based 
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lesson to explore the possibility of water on Mars using MOLA data) and assessment tools. Both 
of these examples put learners in the driver’s seat for exploration of space science data. 

4.6 IT Programs and their FY2001 and FY2002 Investments 

Information technology research and development is funded by a variety of OSS and OAT 
programs. This section is intended to provide a summary of these programs and their 
investments. When evaluating the impact of these investments, it is important to place these 
investments in perspective. Information Technology is a very broad field that covers an 
extremely wide range of topics. Furthermore, much of this investment is in low and mid TRL 
research. Maturation of this research and the eventual infusion of the research into a mission can 
easily take 10 years within NASA since technology development is often frozen 5 years before 
launch for a NASA mission. The missions that we are conducting today are seeing the benefits of 
the investments over the last 5 to 10 years. To evaluate this benefit and compare it against the 
cost of the investment, it is necessary to look at the magnitude of this investment in the past not 
at its current level. 

For each program, this section provides a brief overview, detailed funding information on their 
investments and information about changes for FY02. Note that many of these programs are 
undergoing significant changes from FY01 to FY02. For the purposes of this study, we have 
limited the scope of the assessment to those programs that either explicitly focus on the OSS 
needs or are cross-enterprise in nature. While work developed within other technology programs 
may also eventually benefit OSS, it is difficult to quantify and measure this since the impact is 
diffuse in nature. Furthermore, a comprehensive analysis of these investments was outside the 
scope of this assessment. For cross-enterprise programs, an assessment was also made of the 
percentage relevance to OSS to generate a weighted investment. The weighted investment 
dollars can be used to gain a rough estimate of the agencies IT investment relevant to OSS. The 
relevance measure is a qualitative assessment derived from either a detailed review of the tasks 
or made by the program manager. Thus, a rating of 70% means that 70% of the investment has 
some direct relevance to OSS. Note that for a single program, the sum of the relevance measure 
if applied to each enterprise would be greater than 100% since most of the tasks are relevant to 
more than one enterprise. At the end of this section, a brief description is provided on some of 
the other IT programs within the agency. 

4.6.1 FY2001 Program 

A brief summary of the investments for the programs discussed below is presented in Table 4-3. 
Two different columns are used to describe the FY01 investment. The first column is the total 
investment while the second column is weighted by the relevance of the various portions of the 
program to OSS for the cross-enterprise programs. 
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Table 4-3. FY2001 IT Funding 


Program 

Enterprise 

Investment 

m 

Weighted 
Investment ($K) 

Thinking Systems (Space-based) 

R 

8,163 

7,801 

Intelligent Systems 

R 

32,000 

22,526 

HPCC 

R,S,Y,F 

77,203 

37,370 

SAIT 

S 

2,500 

2,500 

AISRP 

S 

2,500 

2,500 

Mars Technology Program 

S 

5,420 

5,420 

Interplanetary Network and Information 
Systems Technology Program 

S,M 

4,533 

4,083 

New Millennium Program 

S 

460 

460 

ISE/NGI 

R 

18,000 

7,200 

IT-Base 

R 

49,000 

0 

Total Investment ($K) 


199,779 

89,860 


Here is a brief key to the funding information that we have tried to provide for each program. 


• Technology areas: breaks down the investments within the program into the five technology 
areas identified within this report. 

• FY01 investment: total investment in FY01 by investment areas. 

• Intended relevance to OSS: For cross-enterprise programs, this is a number from 0 to 1 to 
evaluate the percentage of direct relevance to OSS needs for each of the investment areas. 

• FY01 investment adjusted for relevance: multiplies the FY01 dollars by the relevance to OSS 
to get a weighted investment. 

Space-Based Thinking Systems Program 

The Thinking Systems program has been part of the Cross-Enterprise Technology Development 
Program. This program was intended to address a broad range of agency cross-enterprise needs. 
It used to be run out of OSS although it was switched to OAT a few years ago. Over the last few 
years, this program has seen a significant reduction in the funds available within the program. 
FY01 is the last year of the program with the funds and tasks being transitioned into various 
different programs in FY02. The Thinking Systems element is being moved into the CICT 
program. 

The Thinking Systems Program has historically addressed many of the same research areas as 
the new Intelligent Systems Program. In fact, it was the success of the Thinking Systems 
program in Remote Agent and through other projects that led in part to the development of the 
Intelligent Systems program. The Intelligent Systems program was sold as an augmentation to 
the existing investment in this area under the Thinking Systems element. For FY02 the tasks 
from the Thinking Systems program and the support for these tasks has been moved into the 
Intelligent Systems portion of the CICT program. 

FY200I funding for the Thinking Systems program is shown in Table 4-4. 
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Table 4-4. FY2001 IT Funding by the Thinking Systems Program 



Technology Areas 

Investments 

($K) 

Weighted 
relevance to 
OSS 

Relevance 
weighted 
investment ($K) 


Highly Robust Autonomous Systems 

4799 

1 

4,799 


Software Engineering and Highly Reliable Software 

884 

1 

884 


Computing Communications and Distributed Systems 

130 

1 

130 


Virtual Mission Operations/Human Machine Systems 

1208 

0.7 

846 


Science Data Processing, Access, Analysis & 
Knowledge Discovery 

1142 

1 

1,142 

w 

Other 

Total Investment ($K) 

8163 


7,801 


Changes in FY02 





• Integrated into CICT. FY02 continues funding competitively selected tasks in their last year. 


i xs? 


i'w 


l ^' 





! W 

: ^ 

? ^7 

: ^ 

] v,/ 

: ^ 

' 

1 V./ 

! 

! XJ 

i V_- 


Intelligent Systems 

FY01 was the first full year of the Intelligent Systems Program managed by Ames research 
center. This program is a basic research program that is performing research in the areas of 
Automated Reasoning, Human-Centered Systems, Intelligent Data Understanding and 
Revolutionary Computing. While its focus is on TRL 1 through 3 technology, the program has 
spike investments that will mature selected technologies as high as TRL 6. In addition to 
investments within NASA, the IS program has been directed by OMB to build a broader research 
community that includes significant university participation. Close to 50% of the IS budget is 
spent on university directed research allocated through competitive selection. A primary 
enterprise has been identified for each of the program elements. Most of the spike investments 
that will mature technologies up to TRL 6 will use an application from this primary enterprise to 
help focus the research while it is maturing. 

As shown in Table 4-5, the total funding for this program was $32M in FY01 and it is expected 
to go up to $49.4M in FY02. Of this amount, $3M has been allocated to one of the new Research 
and Engineering Technology Institutes that are being started this year. 


Table 4-5. FY2001 IT Funding by the Intelligent Systems Program 


Technology Areas 

Investment 

($K) 

Weighted 
relevance to OSS 

Investment adjusted for 
relevance ($K) 

Highly Robust Autonomous Systems 
Software Engineering and Highly 

10,477 

1 

10,477 

Reliable Software 

Computing Communications and 

Distributed Systems 

Virtual Mission Operations/Human 

1,584 

1 

1,584 

0 

Machine Systems 

Science Data Processing, Access, 

8,173 

0.4 

3,269 

Analysis & Knowledge Discovery 

7,617 

0.4 

3,047 

Other _ 

4,149 

_ 1 

4,149 

Total Investment ($K) 

32,000 


22,526 
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Changes for FY02 

• The IS budget is $49.4M for FY02 and it is expected to increase to its full amount of $67M 
for FY03 and beyond. 

• The IS program is one of a number of programs that have been integrated into the CICT 
program in FY02. More details about this information is provided at the end of this section. 

High Performance Computing and Communications (HPCC) 

The HPCC program is a focused program in the area of high-end computing and networking. 
The bulk of the investments are in the TRL 4 to 6 range. In FY01, the OAT and Code Y 
investments was about $22M while the OSS investment was about $19M. The bulk of the OAT 
investment was focused on the needs of the OAT customers while the Code Y investment has 
about 50% relevance to OS S. All of the investment in this area falls under the computing, 
communications and distributed systems technology area. Table 4-6 shows the FY2001 funding 
for the HPCC program. 


Table 4-6. FY2001 IT Funding by the HPCC Program 


HPCC Level 2 

Investing 

Code 

Investment 
Amount ($K) 

Weighted 

OSS 

Relevance 

Weighted 
relevance 
investment ($K) 

Computational Aeroscience 

R 

23,403 

0.0 

0 

Learning Technologies Project 

F 

4,000 

0.2 

800 

NASA Research and Education Network 

R.Y 

3,100 

0.25 

770 

Earth and Space Sciences Project 
Remote Exploration and Experimentation 

Y 

21,800 

0.5 

10,900 

Project 

Total Investment ($K) 

S 

24,900 

77,203 

1 

24,900 

37,370 


Changes in FY02 

• Both OAT and OSS are terminating their portions of this program for FY02. 

Mars Technology Program 

The Mars Technology Program is intended to develop a broad range of technologies to meet the 
needs of the Mars Program. About 80% of the investment is focused directly on developing 
technology for the planned missions with the remaining 20% develops a broader set of 
technologies for longer term exploration plans. Of course, only a portion of this program is 
focused on information technology. A rough estimate of the funded tasks identified a total 
investment of about $5.4M focused on IT as shown in Table 4-7. Since the Mars Program is a 
OSS program, all of the program is clearly relevant to the OSS needs. 
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Table 4-7. FY2001 IT Funding for the Mars Technology Program 


Technology Areas 

Investment 

($K) 

Highly Robust Autonomous Systems 

2,280 

Software Engineering and Highly Reliable Software 
Computing Communications and Distributed Systems 

1,740 

Virtual Mission Operations/Human Machine Systems 

Science Data Processing, Access, Analysis & Knowledge Discovery 

1,400 

Total Investment ($K) 

5,420 


Changes for FY02 

• The Mars Technology Program is undergoing major changes due the postponement of Mars 
07 to Mars 09. This has resulted in a total cut of $5M0. Almost all of the IT investment has 
been eliminated due to this cut. 

Other OSS Programs 

In addition to the programs listed above, there are three other OSS programs that have 
investment in the IT area: AISRP, the Interplanetary Network and Information Systems Program, 
and New Millennium Program. We have not obtained any information about the funding for 
AISRP so not information is provided. The other two programs have limited investments in this 
area at the current time. Both programs are designed as mid to high TRL programs. The numbers 
are only included for one of these programs in Table 4-8. 


Table 4-8. FY2001 IT Funding for the Interplanetary Network and 
Information Systems Technology Program 


Interplanetary Network and 
Information Systems 
Technology Program 

Investment 

($K) 

Weighted OSS 
Relevance 

Weighted relevance 
investment ($K) 

Code M Funded Activities 
OSS Funded 

2578 

1955 

0.82 

1 

2,128 

1,955 


IT-Base Program 

In addition to the programs listed above OAT also has an investment of about $46M in the 
Information Technology Base program. This program is a low-TRL program that has historically 
been focused on OAT IT needs. While much of the research may eventually be relevant to OSS, 
it has not been focused on their needs and as a result would only be diffusely relevant. Work 
within this area includes neuroengineering for adaptive control of damaged airplance, high 
reliability software, and knowledge management for advanced aero-dynamic simulation and 
wind tunnel data. Detailed information is not provided for the funding for this program. 

4.6.2 FY2002 Program 

As mentioned in each of the sections above, a number of major changes are occurring between 
FY01 and FY02. Here is a brief list of these changes: 

• The OAT IT programs are all being combined into the CICT Program. 
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• OAT has a new initiative called Engineering for Complex Systems. The funding for this 
program is $28M for FY02. This is a cross-enterprise, mid-TRL program that has significant 
relevance to OSS. A significant portion of the program is in information technology 
investments. 

• Both the OAT and OSS portions of the HPCC program have been terminated for FY02. 

• The IT investments from the Mars Technology Program have been eliminated for FY02 due 
to major cuts to the program. 

• The Intelligent Synthesis Environment program has been terminated for FY02. 

The total impact of these changes is a decrease of about $34M dollars between FY01 and FY02 
for the OAT investments, with a corresponding reduction of about $12M in OSS-relevant 
research (shown in Table 4-9). 


Table 4-9. FY2002 IT Funding 


Program 

Enterprise 

Investment 

<$K) 

Weighted 
Investment ($K) 

HPCC 

R,S,Y,F 

24,900 

11,250 

Mars Technology Program 

S 

6,000 

6,000 

Interplanetary Network and Information 
Systems Technology Program 

S,M 

4,119 

3,669 

New Millennium Program 

S 

1,546 

1,546 

Engineering for Complex Systems 

R 

13,400 

7,500 

Computing, Information and Communication 
Technology 

R 

115,615 

47,681 

Total Investment ($K) 


165,580 

77,646 


4.6.3 Scope of Assessment 

There appears to be a large gap between the IT research funding identified above with relevance 
to OSS (together totaling about $200M) and that suggested by HQ at the beginning of this study 
(upwards of $250M). Moreover, the Technology Inventory Database lists over $428M of tasks 
in Autonomy and Information Systems for FY01. It appears difficult to reconcile these 3 sets of 
numbers, but it should be clear that this report describes mainly the work represented by the 
smaller number (i.e., ~$150M, excluding the $49M from IT-Base). 
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5. Non-NASA IT R&D Programs (Scope, Drivers, Role) 

5.1 National Science Foundation (NSF) 

NSF’S Directorate for Computer and Information Science and Engineering (CISE) has three 
goals: 

• To enable the United States to uphold a position of world leadership in computing, 
communications, and information science and engineering 

• To promote understanding of the principles and uses of advanced computing, 
communications, and information systems in service to society 

• To contribute to universal, transparent, and affordable participation in an information-based 
society. 

To achieve these goals, the CISE Directorate supports investigator-initiated research in all areas 
of computer and information science and engineering; helps develop and maintain cutting-edge 
national computing and information infrastructure for research and education in general; and 
contributes to the education and training of the next generation of computer scientists and 
engineers. 

CISE activities are core to NSF's efforts in information technology, including the Information 
Technology Research Program. Several CISE programs directly relate to the aims of the NASA 
OSS Themes. 

5.1.1 Overview of Relevant NSF CISE Programs 
Robotics and Human Augmentation 

Supports research fundamental to the design of machines and systems that implement some 
characteristics of intelligence, so that the machines can serve effectively to augment human 
activities. Research topics include machine sensing, perception, and action; automatic 
representation, reasoning, and planning for complex physical tasks involving temporal and 
spatial relationships; integration of sensing and modeling of task environments; hardware and 
algorithmic design of robotic systems, including micro- and nano-scale systems; communication 
and sharing of task control between human and machine and among machines; and linkage and 
cooperation among geographically-separated robotics resources. 

Advanced Computational Research 

Supports a range of enabling technologies needed to advance the state of the art in high- 
performance computing, and brings advanced computing and simulation capabilities to bear on 
fundamental problems throughout science and engineering. Technologies of particular interest 
include (1) data handling and visualization; (2) scalable systems; and (3) high-performance 
algorithms and applications. 

Software Engineering and Languages 
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Supports fundamental research underlying the development and evolution of quality software- 
based systems. Projects may study or develop methods, processes, tools, or environments, taking 
a conceptual, experimental, or developmental approach, or may represent innovative work in the 
theory and design of programming languages, language semantics, and programming 
environments. Specific research topics include domain-specific languages for specification and 
design; constructive approaches to software design and evolution; issues of software modularity 
and composition; enhancement of confidence and quality; automating stages of software 
development; distributed and network environment issues, including distributed development 
and software security; and formal foundations for all aspects of software engineering and 
programming languages. 

Networking Research 

Focuses on the fundamental science and technology needed to facilitate the efficient high-speed 
transfer of information through networks and distributed systems. Projects funded range from 
network design and performance evaluation to middleware and software frameworks in support 
of applications running on top of networks and distributed systems. Projects may also address 
how networks and distributed systems interact with underlying communications technology and 
with other related disciplines. Research areas include high-speed, optical, wireless, and mobile 
networks; traffic control; resource management; quality of service; protocols; multicast; network 
security, design, and management; performance evaluation; network architectures; network 
systems; object-oriented frameworks for networks; agent-based networks; multimedia 
applications; and multiple-access protocols. 

5.1.2 Overview of the NSF Information Technology Research (ITR) Program 

The NSF ITR program is a five-year priority area for research at the intersection of information 
technology and the sciences. It began in FY 2000 as a $90M, cross-Foundation program, and is 
funded at $215M in the current (FY 2001) fiscal year. There are three sizes of research awards 
made in the program: small awards of up to $500,000 total award, usually for individual 
investigators embarking on a new direction of multidisciplinary research involving information 
technology; medium awards of up to $5M total award that typically funds collaborations across 
several disciplines; and center-level awards of up to $15M total award to fund multidisciplinary, 
collaborative efforts that have significant impact on the larger community of scientists and the 
public as well. The program was developed in response to the Presidential Information 
Technology Advisory Committee suggesting to the President that the country was significantly 
under-invested in information technology research. In the final three years, the program is 
expected to grow beyond its current level and then be folded into continuing efforts across the 
Foundation. 

Outcomes of the program are primarily new ideas, new research staff, and new, information- 
based tools for the conduct of science. The Foundation’s mission is at the beginning of the 
research life-cycle, meaning that transitions of research results into new products for both 
government and public use will rely on development elsewhere. The results of the ITR program 
are expected to seed transformations of both science and society at fundamental levels. 
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5.1.3 Potential for Collaboration with NSF ITR Program 

The NASA OSS Theme needs are Autonomy, High Performance Computing. Highly-Reliable 
Software, and Simulation and Modeling. The ITR program vision for FY 2003 includes 
Enabling Research on Software and Hardware Systems, Augmenting Individuals and 
Transforming Society, and Scientific Frontiers of Information Technology. The call for 
proposals for FY 2002 is also structured to represent this vision. Within the theme of enabling 
research, proposals will be awarded in high-performance computing and reliable software. 

Within the theme on the Frontiers of IT, awards will be made in simulation and modeling across 
all of the sciences. The overlap between the NASA themes and the ITR themes affords 
significant opportunity to collaborate. Plans are currently being considered to collaborate on 
funding an ITR large proposal this fiscal year in the development of rovers to collect data on 
glaciations in Antarctica: A Mobile Sensor Web for Polar Ice Sheet Measurements, University of 
Kansas (0122520) $5.49M, plus ~$2M of NASA support. A brief description of this task 
follows. Although the immediate impact of sea level rise (from melting of polar ice sheets) may 
be less severe than other effects of global climate change, the long-term consequences can be 
much more devastating since nearly 60% of the world population lives in coastal regions. 
Understanding the interactions between the ice sheets, oceans and atmosphere is essential to 
quantifying the role of ice sheets in sea level rise. This research project involves the innovative 
application of information technology in the development and deployment of intelligent radar 
sensors for measuring key glaciological parameters. Information on near-surface internal layers 
will be used to estimate the average, recent accumulation rate, while the deeper layers provide a 
history of past accumulation and flow rates. A tracked vehicle and an automated snowmobile 
will be used to test and demonstrate the utility of an intelligent radar in glaciological 
investigations. 

Collaborations can be developed between the two agencies by either transfer of money to NSF to 
assist in the costs of projects in which there is common interest or by each agency providing 
funds to the projects separately. Both mechanisms are currently in use between NSF and other 
agencies, e.g., DARPA and several institutes of the NIH. In either case, it is helpful to have a 
memorandum of understanding between the agencies and NSF that described the scope and 
mechanism of the arrangements. Such agreements are a prelude to either a joint solicitation for 
proposals or interagency co-funding of projects under existing programs or solicitations. These 
agreements are usually signed by senior management in each agency prior to entering into such 
joint activities. 

5.1.4 Transition Issues for NSF ITR Program 


v 

v 

fjg? 


The infusion of IT to customers and products is not a function of the National Science 
Foundation except as the technology provides tools for the conduct of science, such as 
infrastructure or data. The best example of this was the NSFNET, related networking 
technologies, and the first public web browser that effectively transitioned the ARPANET into 
the INTERNET and the World Wide Web. NSF-sponsored research normally does not transition 
into use until several years after NSF funding has ended. 

There has been recently, a series of planning efforts to increase infrastructure support for science 
and engineering research across the Foundation. This is a type of research transition that directly 
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affects science and engineering research. As such, these efforts are directly in support of 
“customers” of the NSF, that is the community of scientists and educators. The recent NSF ITR 
Program announcement states that IT is essential for our economy, our research, our education, 
and many other areas of life. Critical national problems in health care, the environment, 
government operations, teaching and scholarship all require IT knowledge for their solution. The 
solicitation requests proposals that address fundamental research and education in IT; IT 
implications for individuals, society, and scholarship; or application areas at the intersection of 
IT and other science or engineering disciplines. 

5.1.5 Summary of NSF ITR 

• $90M in 2000, ~$2 1 5M in 200 1 and ~$2 1 5M in 2002 

• NSF Technical Advisory Committee- “federal support for long-term research on IT has been 
dangerously inadequate” 

— Why? - boost to the discovery phase of sciences -sensing, data sharing, collaborating 
sharing of hypotheses 

• What is IT? Multidisciplinary focus 

— CS, infrastructure, fundamental new theory as in biology 

• Infusion of IT to products is not an NSF mission 

• Collaboration opportunities 

— Research on architectures, scaling, robustness, embedded software 

— Research on multimodal-multilingual interaction, digital libraries, social impacts of IT, 
organizational IT, educational technology 

— Algorithms, databases, tools, modeling, visualization, applications in the sciences 

• Existing MOU examples 

— Biocomputing MOU with DARPA 

— Neuroinformatics MOU with NIH 

• Plans with NASA are currently being considered to collaborate on funding an ITR large 
proposal this fiscal year in development of rovers to collect data on glaciations in Antarctica 

• Most larger ITR awards this FY are infrastructure research, e.g., “mobile sensor web for 
polar ice sheet measurements” 

A high-level breakdown of NSF IT funding is shown in Figure 5-1. 

5.1.6 Summary of NSF Computer and Information Science and Engineering 
Advanced Computational Infrastructure and Research 

Advanced Computational Infrastructure and Research provides access to, and support of, high- 
end computing infrastructure and research for the national scientific community through the 
Partnerships for Advanced Computational Infrastructure program, and through the Advanced 
Computational Research program. 
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Advanced Networking Infrastructure and Research 

Advanced Networking Infrastructure and Research is concerned with Advanced Networking 
Research (ANR) and Advanced Networking Infrastructure (ANI). 

Computer-Communications Research (C-CR) 

C-CR supports research in a broad array of areas including design automation; computer systems 
architecture; software engineering and languages, operating systems and compilers; theory of 
computing; numeric, symbolic, and geometric computation; communications; and signal 
processing systems. 

Experimental and Integrative Activities (EIA) 

EIA promotes the development of experimental computer and communications research, furthers 
the evolution of multidisciplinary research involving CISE and other disciplines, contributes to 
the creation of a diverse personnel pool, carries out exploratory and prototype projects crossing 
organizational boundaries, operates special international activities, and supports special studies 
and analyses on issues affecting CISE disciplines. 

Information and Intelligent Systems (IIS) 

IIS strives to increase the ability to use information for human ends by supporting research to 
improve the ability to generate, store, organize, locate, communicate, and store knowledge using 
new technologies. This recognizes that high quality content, its accessibility, and its usability are 
important benefits provided by new technology, and are complementary to bandwidth and disk 
space. 


FY’02 

$470M 


Computing and 
Communications 
Research 
14% 



Advanced 
Networking 
Infrastructure and 
Research 
14% 


Information and 
Intelligent Systems 
10% 

Experimental and 
Integrative 
Activities 
12 % 


Advanced 
Computational 
Infrastructure and 
Research 
17% 


Figure 5-1. Computing and Information Science and Engineering Breakdown 
(includes ITR and other Information Technology Programs) 
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5.2 Defense and Advanced Research Projects Agency (DARPA) 

DARPA is the technical change leader for the Department of Defense. Its mission is to promote 
revolutionary technical innovations to support our national security. Current DARPA research 
includes information technology, space, biological warfare, micro systems, and material research 
for our military forces to achieve full spectrum dominance. DARPA maintains a focus on high- 
risk research and unlike the services, it does not manage formal acquisition programs (i.e., as 
mandated by the DOD 5000-series policy documents). Thus, DARPA complements, but is not a 
substitute for, the service science and technology and acquisition organizations. 

5.2.1 Information Technology Office Programs 
Architectures and Design 

Autonomous Negotiating Teams 

The Autonomous Negotiating Teams program develops software technology to resolve time- 
critical constraints in logistics and mission planning, including integrated maintenance and 
mission planning to support the operation of Marine Attack Squadrons, real-time mission 
planning and dynamic replanning experiments for UCAV operation, and adaptive scan- 
scheduling for electronic warfare platforms. 

($13.9 M) 

Compo sable High Assurance Trusted Systems 

The CHATS program is developing the tools and technology that will enable core systems and 
network services to protect themselves from the introduction and execution of malicious code 
and other attack techniques and methods. 

($7.4 M) 

Control of Agent Based Systems 

Information superiority in the modem battlefield requires the military to have the ability to 
rapidly assemble a set of disparate information systems into a coherently interoperating whole. 
This must be done without system redesign and may include interoperation with non-DoD 
governmental systems, systems separately designed by coalition partners, or with commercial- 
off-the-shelf and open-source systems not built to a pre-existing government standard. The 
CoABS program is building on the technology of run-time interoperability of heterogeneous 
systems to develop new tools for facilitating rapid system integration. 

($9.9 M) 

DARPA Agent Markup Language 

The DAML program is creating technologies that will enable software agents to identify, 
communicate with, and understand other software agents dynamically in a web-enabled 
environment. Agents, (software that runs without direct human control or constant supervision 
to accomplish goals specified by the user) can be used to collect, filter, and process information - 
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a crucial need of command and control intelligence, surveillance, and reconnaissance 
($15.9 M) 

Dynamic Assembly for Systems ' Adaptability, Dependability, and Assurance 

The DAS ADA program is developing dynamic gauges or measures of component composability 
or interoperability that will enable software components from any source to support assured 
applications and reconfiguration. 

($10.9 M) 

Model-Based Integration of Embedded Software 

The MoBEES will establish composability of large embedded software applications for temporal, 
noise, synchronization, and dependability constraints. To do this we will use customizable 
frameworks and model-based integration technology. 

($12.9M) 

Networked Embedded and Autonomous Software Technology 

The NEST program is developing application-independent, customizable, and adaptable services 
for the real-time fine-grain distributed control of physical systems. The quantitative target is to 
build MEMS-based, dependable, real-time, embedded applications (services, protocol libraries) 
comprising 100 to 100,000 computing nodes. 

($11.0 M) 

Polymorphous Computing Architectures 

The PCA program is developing a revolutionary approach to implementing embedded computing 
systems that support reactive multi-mission, multi-sensor, and in-flight retargetable missions and 
reduce the time needed for payload adaptation, optimization, and verification from years to days 
to minutes. This program breaks the current development approach of hardware first and 
software last by moving beyond conventional computer hardware and software to flexible, 
polymorphous computing systems. 

($15.0 M) 

Program Composition for Embedded Systems 

PCES is creating new technology for programming embedded systems that will substantially 
reduce development and validation effort and improve the flexibility and confidence of the 
resulting software. The focus is on formal methods and languages for computer aspect weaving. 
($17.0 M) 

Quorum 

The Quorum program is developing advanced resource management, middleware, and operating 
systems technology that will allow mission-critical applications with widely varying 
characteristics to share a common pool of networked, commercial-off-the-shelf processors, while 
still meeting their real-time deadlines. This technology allows resources to be dynamically 
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allocated to the most critical applications when experiencing workload surges, failures, and 
threat or mission mode changes, while still ensuring that other applications receive acceptable 
quality of service. 

(ends in FY01) 

Taskable Agent Software Kit 

The TASK program will extend the current scientific and mathematical foundations of agent- 
based computing with the goal of adding rigor to the engineering of agent-based systems. 

($6.9 M) 

Advanced Processing and Storage 

Bio-Computation Program 

The Bio-Computation Program is exploring and developing computational methods and models 
at the bio-molecular and cellular levels for a variety of DoD and national security applications. 
The program is developing powerful, synthetic computations that can be implemented in bio- 
substrates and computer-aided analytical and modeling tools that predict and control cellular 
processes and systems of living cells. 

($16.0 M) 

Data Intensive Systems 

The Data Intensive Systems program is developing software and hardware technologies that will 
enable the full use of increased processing element capability and eliminate the under-utilization 
of system resources due to the restricted data flow and high latency found in current memory 
implementations. 

(ends in FY01) 

High Performance Computing Systems 

The HPCS program will provide a new generation of economically viable high-productivity 
computing systems by implementing a holistic approach to high-end architectures and software 
tools and environments and addressing technical issues of performance, productivity, portability, 
and robustness. 

($20.0 M) 

Power Aware Computing/Communication 

Energy and power management has now become a critical factor for future embedded and large 
scientific computing applications. The PAC/C program is developing an integrated software/ 
hardware power management technology suite comprised of novel techniques that may be 
applied at all levels of a system - from the chip to the full system. This will enable embedded 
computing systems to reduce energy requirements by a hundred- to a thousand-fold in such 
military applications ranging from hand-held computing devices to unmanned air vehicles. 
($16.0 M) 


170 


Chapter 5. Non-NASA IT R&D Programs 


Quantum Information Science and Technology 

The QuIST program is developing information technology devices and systems that leverage 
quantum effects and technologies for scalable, reliable, and secure quantum computing and 
communication. Quantum computers and communication systems are potentially much more 
capable and secure than today’s systems and can serve DoD’s increasing need for secure 
communication and computational power to meet the stringent requirements of military data and 
signal processing. 

($9.0 M) 

Networks 

Active Networks 

The goal of the Active Networks program is to develop and test a protocol architecture that 
allows rapid and dependable creation, reconfiguration, and deployment of new networking 
services. Such deployment is not possible with today’s existing networking infrastructure, which 
relies on a uniformly standardized software base. Active Networks will achieve this goal 
through the concept of SmartPackets, self-directed data units, which can direct their own 
processing and deliver new services to the interior network nodes. 

($9.8 M) 

Gigabyte Applications 

The Gigabyte Applications program is developing technologies for a highly robust, high-speed 
networking infrastructure in a heterogeneous environment. By extending high-bandwidth 
capability to wireless links, it will be possible to deploy high-speed networks with many 
hundreds-of-megabit- to gigabit-per-second capacity in remote tactical locations with no pre- 
existing fiber infrastructure. 

($24.7 M) 

Network Modeling and Simulation 

The goal of Network Modeling and Simulation is to create tools that are trustworthy to predict 
with known accuracy network behavior at varying time scales and for different network sizes and 
composition. These tools, along with an appropriate on-line network measurement methodology 
to be developed in this program, will provide a basis for on-line network control, dramatically 
reducing the time and cost required for functions such as parameter tuning, fielding new and 
situation-specific protocols, and QoS provisioning. 

($9.9 M) 

Next Generation Internet 

DoD applications are highly bandwidth-intensive, and their demanding requirements cannot be 
met by the commercially-developed networking technologies that are optimized for web- 
browsing and low data-rate data streaming. The Next Generation Internet program, ending this 
year, has developed the key technologies, both in hardware and software, to enable access to 
extremely high bandwidth. The program has deployed a national-scale SuperNet testbed that ties 
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together several dozen sites at multi-gigabit rates. 

(ends in FY01) 

Sensor Networks 

Small, miniaturized, low-cost sensors will become more capable and pervasive in future military 
systems to detect ground-moving targets and biological and chemical warfare agents, and for 
military operations in urban terrain. To fully utilize these sensor capabilities, we must develop 
software that can create an ad-hoc network of deployed sensor devices, and process information 
collected by the sensors for reconnaissance, surveillance, and tactical uses for the war fighter. 
The SensIT program is producing software that enables flexible and powerful sensing 
capabilities for networked micro-sensors. 

($16.8 M) 

Human-Computer Interactions 

Communicator 


The goal of the DARPA Communicator program is to develop and demonstrate “dialog 
interaction” technology that enables warriors to talk with computers. Information will be 
accessible on the battlefield or in command centers without ever having to touch a keyboard. 

The “Communicator” will be wireless and mobile, and will function in a networked 
environment. 

($8.9 M) 

Information Management 

The IM program is: (1) developing repository technology to rigorously register, classify, and 
manage multimedia document streams; (2) integrating knowledge-based and statistical analysis 
techniques to extract critical information from large multi-source collections automatically; and 
(3) evaluating the potential of machine translation technology to support multilingual 
information analysis. 

(ends in FY01) 

Mixed Initiative Control of Automa-Teams 

The MICA program will develop enabling technologies for applying the collective power of 
teamed automatons to representative military operations in the presence of human operators. 
MICA will develop the theory, algorithms, software, and modeling and simulation technologies 
to coordinate the multi-level planning, assessment, and operation of distributed semi-autonomous 
forces with collective objectives through the hierarchical application of systems and control 
theoretic methods. 

($10.0 M) 

Rapid Knowledge Formulation 

At present, complex military problem-solving tasks are either performed entirely by human 
operations officers and intelligence analysts, or with minimal assistance by small knowledge 
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bases. The RKF project continues to develop methods to conduct rapid database searches, 
construct knowledge bases, and draw inferences for key information. The RKF program is 
enabling end-users to directly enter knowledge into knowledge bases and to create massive 
knowledge bases (106 axioms) in less than one year. It will allow artificial intelligence novices 
to directly grasp the contents of a knowledge bases and to compose formal theories without 
formal logic training. 

($13.0 M) 

Software-Enabled Control 

The goal of the SEC program is to leverage increased processor and memory capacity to achieve 
higher performance and more reliable software control systems for mission system platforms. 
($19.3 M) 
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Translingual Information Detection, Extraction, and Summarization 

The TIDES program is creating technology to enable English speakers to locate, access, and 
utilize network-accessible information in multiple languages without requiring knowledge of 
those languages. 

($19.8 M) 

Ubiquitous Computing 

A grand challenge for information technology is bridging the gap between the physical and 
digital worlds. Computers should disappear into the background while information becomes 
ubiquitous. The Ubiquitous Computing program focuses on developing the underlying 
technologies to provide accessible, understandable, relevant information to mobile users, based 
on an understanding of the user’s tasks and informational needs, to provide the warfighter with 
greater and more timely situational awareness - thereby increasing his survivability, lethality, 
and effectiveness. 

($8.7 M) 

Large Scale Applications - Robotics and Intelligence/Force Protection 

Mobile Autonomous Robot Software 

The MARS program is developing software technologies that can enable machine-learning 
strategies to automatically generate sophisticated robot behaviors such as autonomous navigation 
and real-time obstacle avoidance. These sensor-mediated behaviors will reduce the requirement 
for remote operator control for robots employed in tactically realistic environments including 
complex, dynamic environments such as urban combat battlespaces. 

($19.0 M) 

Software for Distributed Robotics 

The SDR program is developing robot software technologies to allow a single soldier to interact 
naturally with and intuitively control a large swarm of very small micro-robots performing a 
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collective task. 

($7.9 M) 

Bio-Surveillance 

The Bio-Surveillance program is developing, testing and demonstrating the technologies 
necessary for the early detection of a clandestine release of a bio-pathogen by monitoring non- 
traditional data sources. 

($8.0 M) 

Human Identification at a Distance 

The HumanID is developing automated multi-modal surveillance technology for identifying 
humans at a distance using different biometrics techniques such as face and body parts 
identification, infrared and hyper-spectral imagery, gait and temporal human dynamics, non- 
imaging physiological based-biometrics, and remote iris scan. 

($15.9 M) 

5.2.2 Potential Areas for Collaboration with NASA OSS 

While DARPA’s primary mission is to serve the needs of our military services and DoD 
components, these often coincide with the needs of other agencies. Particularly because of 
NASA’s involvement in space, the overlap may be quite strong. Many of the NASA IT needs 
identified in the June symposium coincide with research being done at DARPA. However, since 
NASA is involved in only a small number of these programs to date, the research may not cover 
NASA requirements. The best way to explore the possibilities of joint efforts is to talk with the 
Program Managers, get a detailed understanding of what they are pursuing and not pursuing, 
discuss mutual areas of interest and possibilities, and look for flexibility in the programs’ current 
schedules and funding to accommodate change and/or to participate in our conferences and 
research evaluations. 

NASA OSS needs cover a broad spectrum of information technology. Each of the paragraphs 
that follow discusses some of the critical components and DARPA ITO and ISO research in that 
area. 

One of the key components is the need for understanding how to build complex information 
systems. This includes the architecture and design of the algorithms, software and systems that 
drive our embedded and large scale applications. We need to move towards runtime 
assembly/integration/re-assembly of components. We need to be able to understand the 
functioning of the software through simulation models that allow us to tweak and adjust 
performance. And, we need to be able to thoroughly test the software to validate and verify its 
potential functioning. DARPA’s efforts in this area are: for embedded system design, the 
MOBIES program; for networks, the Network Modeling and Simulation program; and for large- 
scale systems and system self-monitoring and self-healing, the DASADA program. More 
intense investigation into the architecture and design and simulation capabilities is currently 
under consideration. 
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NASA’s onboard computing needs are somewhat addressed in DARPA’s SensIT program, 
focused on processing information gathered by networks of small devices. 

DARPA is addressing human computer interfacing with several lines of attack. The 
Communicator program is a wireless and mobile connection for Warfighters to control 
networked robotics. MICA is applying control theory to model and simulate multi-level 
planning for operations of human and autonomous teams. 

Planning and scheduling needs are addressed as network resource management in QUORUM, 
reactive multi-mission support in embedded systems in PCA, power management research in 
PAC/C, and planning tools in ANTS. 

Robotics initiatives in DARPA are split between two program offices, with ATO doing the 
predominantly hardware activities and ITO performing the software. Our two programs in ITO 
are the MARS for machine learning and sophisticated robot behavior, and the SDR for single- 
person control of large swarms of devices. Giving our autonomous systems high performance 
and reliable control at the edge of performance demands is the research undertaken by SEC. 
NEST focuses on the control of hundreds or thousands of embedded applications. 

Our research for improving communication networks is focused in Active Networks for self- 
directed data units; NGI for end-to-end transmission via TCP/IP on optical media at gigabytes/s; 
Quorum for resource management; and Gigabyte Applications for wireless and wired high- 
bandwidth transmission. 

5.2.3 DARPA Technology Transition 

DARPA transition is a key focus area this year, with Special Assistant to the Director John 
Jennings the DARPA lead. He has initiated the document ‘Technology Transition from the 
DARPA”, from which much of what follows is drawn. 

What Is Technology Transition and Why Is It Difficult? 

The challenge of transitioning new technologies into products and Services used by the final 
customer - that is, the weapon systems acquisition program office or warfighter - is a formidable 
task. Technology transition results in the insertion and fielding of a new or upgraded technology 
or capability into military equipment, software, or processes that support or are used by the war- 
fighter. Within DOD, this typically refers to the transition or insertion of technology from an 
S&T program into a weapon system acquisition program. The technology transition process 
hinges on reducing the risk of a new technology to the point that it becomes more useful for the 
customer than an existing capability, or provides a leap-ahead capability that is worth the 
necessary investment. 

A key reason technology transition is difficult is that it requires the collaboration of three diverse 
groups of individuals - researchers, acquisition program managers, and military users. Each 
group has a vital but unique job. For example, laboratory researchers are, by necessity, risk 
takers. Their job is to invent the breakthrough technologies of tomorrow that provide the 
warfighting edge for the military user. They may learn as much from success and they do from 
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failure. The acquisition or weapon system program manager is necessarily risk adverse, being 
charged to develop and field weapon systems on cost and within schedule that exhibit the 
performance requirements specified by the user. The user, or warfighter, wants the best 
performing system that overwhelms the threat with minimal casualties. Effective transition 
requires these communities to work together as a team, which is frequently a difficult issue. 

Some additional considerations that make transition of technology difficult include the 
following: 

• Evolutionary versus Revolutionary Technology Development. Evolutionary improvements 
in stable technology such as microelectronic devices and information systems may occur 
relatively quickly, and DoD frequently takes advantage of the rapid turnover of changes in 
the commercial market. However, development of revolutionary new warfighting 
technologies that provide our forces the technological leap-ahead advantage on the battlefield 
(e.g., low observables, precision strike, and unmanned systems) may take many years to 
develop and mature in the laboratory environment. Such investments frequently provide 
dramatic war-winning payoffs, as evidenced by such programs as the F-l 17 stealth fighter, 
phased-array radars, uncooled infrared sensors, and unmanned air vehicles. With IT, a 
simple prototype may prove the concept, but it may takes years before it can be incorporated 
into real embedded or application systems for reliable performance. 

• Complex Development Process. New technologies must be vetted, refined, and compete 
against other existing and new technologies for resources. Technologies require marketing 
champions to convince customers and senior DoD managers of the need to invest. These 
customers and managers change over time. Technology passes through various institutions - 
for example, from a university laboratory, to a start-up company, to being used by a major 
manufacturer of defense systems, making the process difficult to track, monitor, and 
measure. Accordingly, the process is nonlinear and sometimes chaotic, rather than a pipeline 
that allows easy traceability from technology invention to fielding. 

• Different Pathways to Transition. The manner in which one moves a technology closer 
toward the user depends on issues such as the type of technology, its maturity, the user, and 
competing technologies. For example, the next steps in transitioning a fundamental research 
6.1 program in quantum computing is different than scaling up processes for 
MicroElectroMechanical devices in applied or advanced technology development programs. 
In the case of basic research programs, years of scientific research may be required in a 
research laboratory or university to understand, validate, and prove out the basic properties of 
a technology. Once proven, industry frequently provides the scale up or manufacturing 
knowledge to insert the prototype demonstrations in a system or subsystem. 

• High Cost of Innovation and Change. While technical improvements are beneficial to 
organizations, they create risks, cost money, and disrupt operations. Hence, many 
organizations, not just military ones, often resist technology innovation because its insertion 
may lead to higher risk and costs. For a technology transition to be successful, the military 
customer and system integrator (e.g., contractor) must be supportive of its insertion, and it 
must demonstrate a greater return than the existing capability. 

In addition to these challenges, DARPA’s role, mission, and charter necessarily impose 
additional demands on the transition process. For example, technologies often take a very long 
time to mature because of DARPA’s mission to pursue high-risk, high-payoff technologies. As 
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an entrepreneurial technical organization, DARPA operates outside the requirements and 
acquisition system, but constantly seeks opportunities to sell new capabilities back to the 
Services and other Defense Agencies. It pursues a wide variety of technologies, many of which 
may have no natural home or existing niche in the Services. Periodically, DARPA creates 
revolutionary technology that provides great benefits, but the breakthrough technology may 
create great costs by making current equipment obsolete, and require major changes to ongoing 
doctrine, organizations and operations. 

DARPA Approaches to Technology Transition 

DARPA’s primary mission requires it to focus its investments on revolutionary breakthroughs, 
rather than near-term technology demonstrations. However, DARPA uses a broad array of 
transition strategies to match the array of technologies that it promotes. DARPA has three 
thrusts to implement its technology transition process, as described below. 

Building on What Works 

Improved dialogue among researchers, acquisition program managers, and military users is an 
effective way to improve the transition of technology. DARPA continues to use technology 
transition strategies, many of which involve teaming with other organizations. Some of these 
strategies include: 

• Jointly Funded Service-DARPA Programs. DARPA and a Service frequently team to 
commit funding to develop a technology for the Service. The different roles and capabilities 
of each organization are defined early on in the partnership. Assuming the technology can be 
properly developed, this is an effective mechanism for transition because the Service 
customer, or weapon system acquisition program, provides the technology pull. DARPA is 
currently funding a number of programs jointly with the Services. A major initiative is 
underway with the Army to collaborate on the Future Combat Systems demonstration 
program. In another example, the Navy and Air Force each has a joint effort with DARPA to 
develop an Unmanned Combat Air Vehicle. 

• Joint Service-DARPA Program Office. DARPA and a Service establish a Joint Program 
Office in which control of the program shifts from DARPA to the Service over time. This 
keeps the Service firmly in touch with the project, shows evidence of Service buy-in, and 
greatly eases the turmoil that can occur when program management changes from one 
organization to another. The Global Hawk High-Altitude Endurance Unmanned Aerial 
Vehicle (HAE-UAV) was transitioned in such a manner. The HAE-UAV Joint Program 
Office, staffed primarily with DARPA personnel, initially managed this Advanced Concept 
Technology Demonstration. As the program matured, the mix changed to include more Air 
Force officers. These officers transitioned with the program as Air Force management 
moved to the Air Force Research Laboratory. 

• Industrial Consortia. While the two methods above are well-suited to military hardware 
subsystem and system level projects, industrial consortia are effective in the development of 
component-level technologies that may have broad application in both commercial and 
military markets. DARPA pioneered many of these arrangements in the early 1990s, 
bringing together DoD and industry to work on problems of mutual interest using mutual 
investments. This method harnesses industry’s self-interest in selling a technology to power 
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its transition. DARPA’s involvement ensures that the technology develops in a way well 
suited for military applications. 

• Improved Understanding. DARPA is taking a close look at how its technologies have 
transitioned in the recent past. The goal is to improve its ability to transition through a better 
understanding of what transition strategies have worked better for which technologies and 
under what circumstances. DARPA is categorizing the successful transition of the 1990s, 
conducting case studies across the offices and fusing the inputs from our Program Managers 
and Office Directors to continue to refine our transition planning. 

Informally, our Program Managers have accomplished significant transition by working directly 
with interested personnel from the Services, the intelligence agencies, and others related to 
military concerns. By identifying crusaders for technology, and engaging them early in the 
program formulation, the procurement write-up and evaluations, and throughout the program as 
unbiased observers and evaluators, we achieve significant military focus and identify strong 
transition paths for the program as it evolves. This allows for the proper planning and 
earmarking of funds to meet the transition needs, whether direct to the operational folks or 
through one of their labs. More formal paths are available through: 

• Advanced Technology Demonstrations. ATDs demonstrate the maturity and potential of 
advanced technologies for enhanced military operational capability or cost effectiveness. 

• Advanced Concept Technology Demonstrations. ACTDs are designed to rapidly transition 
emerging technology to the warfighter. The ACTDs place enough material in the hands of 
the war-fighter to achieve a realistic military evaluation and to provide a limited go-to-war 
contingency capability if the war-fighter chooses to use it. The ACTD program supports this 
residual equipment for two years after the demonstration and evaluation phase to ease the 
transition into the formal acquisition system. 

5.2.4 Summary of DARPA IT Research Program 

• Funding totals around $383.5M/year for DARPA IT R&D 

• Many of the NASA IT needs coincide with research being done at DARPA 

• To date NASA is involved in only a small number of DARPA Programs 

• System software engineering of complex information systems is a necessary part of IT R&D; 
also, the understanding the functioning of software through simulation models 

• All aspects of autonomous systems R&D are being addressed 

• DARPA has a special assistant to the Director for Technology Transition, John Jennings, 
DARPA lead 

• Within DARPA three diverse groups must collaborate- researchers, acquisition PM & 
military users. 

- Friction between risk takers and risk-averse groups. 

• Technology infusion approaches 

- Jointly funded and joint program office 

- Industrial consortia with joint funding 
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- Advanced Technology Demonstrations demonstrationss technology maturity and 
potential 

- Advanced Concept Technology Demonstration achieves a realistic military evaluation 
and places capability into the hands of the war-fighter 

- Possible infusion metrics 

0 Cost sharing/program wedges 
° Prototype is being used 

° Technology changes the way customer does business 
° System program office is established to acquire end-to-end system 
° Service lab funds transition programs 

A high-level breakdown of DARP A IT funding is shown in Figure 5-2. 
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Figure 5-2. DARPA Information Technology Office Breakdown 
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5.3 Oracle 

5.3.1 Overview of Programs at Oracle 

Oracle revenues in FY2001 were $11B, split roughly equally across product licenses and service. 
About 75% of this comes from our Server business and 25% from our Applications business. 

We spent over $1B on Research and Development, the great majority of which would, in NASA 
terms, be classified as Development and Engineering rather than as classical Research. Most of 
the research-like activities we undertake probably would be closer to Advanced Development. 

We do have very active ongoing efforts in the Server arena. Some are spawned as a result of 
existing development efforts; others come from new product requirements. A partial list of 
focus areas includes: 

• Improved operation: performance, scalability, reliability, availability, usability 

• Extending DBMS technology: Internet file system, content management, web caching / 
searching 

• New application development techniques: Java, XML, mobile operation, mid-tier application 
servers 

• Other advanced features: clustered systems, analytic processing, security, directory 
management. 

5.3.2 Opportunities for Collaboration 

We believe there are many opportunities for Oracle-NASA interaction. Oracle is obviously a 
provider of commercial products (both platform and applications) as well as implementation 
services. Collaboration can also provide opportunities to learn together and to influence Oracle 
product development. We are also a practical source of knowledge on the how of software 
development. In summary, we can: 

• Provide and implement Oracle products to be used as standard technology in ground-based 
systems for knowledge capture, development infrastructure, business management and 
operations support, and mission data capture/management/analysis 

• Share our knowledge of how we plan, develop, test, deliver and sustain reliable, commercial 
software across a large-scale, geographically-dispersed development environment 

• Share our insights of how new application design / partitioning architectures are evolving in 
the commercial world (thin client, mid-tier, database) 

• Learn about NASA requirements and use these to influence advanced product development. 

• Participate in the HDCC. 
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5.3.3 Technology Infusion Process 

Technology infusion at Oracle is designed to be rapid. A new technology’s initial incarnation 

usually takes less than one major version (18 months to 2 years) to become part of a released 

product. This comes about through a number of complementary forces and processes. 

• Product managers and developers monitor research activities and maintain their university 
contacts. They also stay abreast of industry developments and competitive products. At 
Oracle, product management is closely aligned with development both practically and 
organizationally. Together they constitute de facto technology teams that all contribute to 
our various releases. 

• We often drive emerging standards, and rapidly adopt those in areas relevant to our business. 
This actually has represented a shift in attitude over the past decade. By embracing 
standards, we can focus our innovation more tightly to competitive advantage and avoid 
reinventing technology with illusory added value. 

• We are in continual contact with customers, who come with many unusual requirements and 
business needs. We intimately engage with customers who are developing a broad-range of 
Oracle-based applications, many of which are leading-edge. Our consulting arm is often 
involved in these implementations. Feedback to development is rapid in any case. On a 
more structured level, we foster a number of Customer Advisory Councils who provide 
requirements input as well as calibrate proposed features and enhancements. We 
complement this with focused Beta Test and Early Adopter programs, as well as the more 
broadly-based Technology Network and the Partner Program. 

• Internal needs often kick off developments that ultimately turn into products. Examples 
include the Email Server, Files Online, and our emerging Software Configuration 
Management System. One tactic that we find exceptionally useful is to roll these out as an 
internal service offering across Oracle prior to external product launch. 

• Asa rule, new database and application server technologies are brought to market by 
becoming elements of an ever-growing server stack or platform. By so doing, new 
technologies benefit from the processes and infrastructure that allow us to mature our 
products as rapidly as possible. Re-use of a technology element is easier and often automatic 
just because it is bundled into an integrated platform. It then joins all the other elements of 
the stack as they fly 50,000 missions a day. 

• One tactic that we use in Server development is to provide the framework for integration 
testing including new features starting from day one. We do not wait until functional 
completion of components to begin integrated testing. The assumption is made that new 
technology will be incorporated into a major product release as soon as possible and that the 
sooner integrated regression testing begins, the better. 

• Oracle tends to be reluctant to acquire technology from outside. It is said that we would 
rather miss a good investment than execute a flawed one. So we would rather build rather 
than buy, but on occasion we have bought and infused both new and replacement 
components quickly. A recent such transitions was the rapid conversion to Apache as the 
basis of our Application Server. 
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5.3.4 Observations on NASA IT Assessment 

Oracle development is a very new participant in collaborations such as the IT assessment. My 

observations will therefore not have much basis in history. With this caution, I offer three topics: 

• Collaboration. A valuable aspect of the process is mission folks and IT providers working 
together. This is a close customer-supplier interaction that I hope would be an ongoing 
process. I know how much Oracle benefits from such intimacy; this should be no different 
for NASA. I have been particularly impressed by the tone of constructive dialogue and 
information sharing. There has not, however, been a similar emphasis on planning for cross- 
enterprise contacts, a key insight from the Ventura conference. 

• Reusable Platform Development. The notion of reusability, especially for in-flight systems, 
seems to be at best weakly supported. The most I heard was that a given site would re-use 
technology it had developed for previous missions, but not that sites would contribute 
reusable components to NASA nor that the Agency would target investment towards 
developing and deepening a re-usable technology stack. A strategy by which a small fraction 
of mission funding could be designated for re-usable platform development and enrichment 
should be considered. This is as much a management challenge as it is a technical challenge; 
assuming shared risk seems difficult for engineers to accept. NASA’s constraints may make 
this especially difficult. Motivating and rewarding both producers and consumers of re- 
usable platform technology across missions must start with an explicit top-down mandate to 
do so. 

• In-Flight Computational Power. A major barrier to the development of a re-usable platform 
stack for NASA in-flight systems is the exceptionally low computational horsepower and 
capacity available to run such a stack. I believe that many (risky?) design tradeoffs are 
sanctioned in order to work around this extreme set of constraints. Since even the most 
carefully designed general systems must consume more processing power than specialized 
systems, should a mission planner spend 5 % to accommodate that generality or do 5 % more 
science? Should the IT community specifically commission research and development to 
provide one or two decimal orders of magnitude more horsepower (at same 
power/space/mass) for in-flight systems? Does research for flight platform infrastructure 
improvement always take a distant back seat to science-related research? 

5.3.5 Summary of Oracle IT Research Program 

• Most research-like activities are closer to advanced development. 

• Foster a number of Customer Advisory Councils who provide requirements. 

— This leads to focused beta test. 

• Does not acquire technology from outside. 
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5.4 IBM Perspective on NASA IT Assessment 

5.4.1 Introduction 

The purpose of this report is to explain how IBM as a company, and the IBM Research Division 
in particular initiate, evaluate, and mature information technology projects, and to relate these 
IBM corporate processes to NASA’s situation. The report was prepared by the author with 
consultation with IBM colleagues, but represents the views of the author, and does not convey 
any IBM corporate endorsements or commitments. 

NASA’s Office of Space Sciences has undertaken a review of the investments it makes in 
advanced information technology projects. One of the fundamental questions of the assessment 
is the relationship of IT investments and programs to missions. Since NASA Office of Space 
Sciences missions are never routine, and always require innovative engineering, the OSS IT 
program has a responsibility to provide many unique information management and 
computational services for end-to-end mission operations including planning, launch, flight, and 
science phases of missions. 

5.4.2 Overview of the Research Division’s Role in IBM and Its Processes 

The IBM Research Division, comprised of eight laboratories worldwide, exists in IBM to 
support all other corporate divisions by infusion of new technologies into product and services 
streams; to bring about invention and innovation by working directly with customers that have 
wants and needs that align with IBM strategies and directions; and very importantly, to be 
distinguished for the quality of its science. The Research Division is global, with labs in 
Yorktown Heights NY, San Jose CA, Austin TX, Tokyo, Zurich, Beijing, Delhi, and Haifa. The 
smaller labs in Asia are mostly focused on issues related to linguist and language problems in the 
area. Austin is focused on hardware research, Almaden in San Jose emphasizes data management 
and all aspects of storage. The T.J. Watson labs in New York are very large, and have a 
comprehensive program. Tokyo and Zurich are also comprehensive. 

The IBM Corporation as a whole invests about $5B annually (From the IBM 2000 Annual 
Report) in company-wide Research, Development, and Engineering. Allocation of this budget is 
done in ways which are intended to allocate, track, and evaluate projects relative to overall 
corporate objectives. In this report, I focus on the Research Division’s approach only. 

The mission of the IBM Research Division is: 

• Perform basic and applied research that is vital to IBM 

• Be recognized for distinguished scientific accomplishments. 

The Research Division’s mission has a science emphasis that takes it beyond product 
development, and IBM has nurtured the dual mission of the Research Division by maintaining 
organizational distinctions between its research laboratories and its product development 
laboratories, notwithstanding the fact that research and product labs collaborate extensively. EBM 
research includes many disciplines, including engineering and physical sciences, and there is 
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significant interdisciplinary interaction, both formal and informal. The Research labs maintain an 
active program of visitors, exchanges with universities, programs for students at all levels, and 
involvement in scientific publication, societies, and professional development. 

While the mission of IBM Research has remained constant over time, the approach toward 
executing it has evolved as the company, and the information technology marketplace have 
evolved. Evolution over three decades is summarized below. 

• 1970s. The division executed a corporately funded research agenda across a very broad range 
of problems and disciplines and transferred sufficiently mature research products into other 
IBM components. 

• 1980s. The division moved to a methodology of more front-loaded technology transfer, 
where Research and IBM component jointly proposed, planned, executed, and most 
importantly, funded research programs called Joint Programs targeted toward the 
cooperating component’s needs. This is a model of research focused on internal customer 
needs. 

• 1990s. The division extended the customer focus to working with external IBM customers 
who brought leading edge challenges, or actively participated in the definition and 
development of new commercial technologies, or were willing to partner as early adopters of 
new ideas. At this point the model has shifted to greater focus on external customer needs. 

• 2000s. The customer focus has become more entrepreneurial and includes activities that 
create commercial advantage or broadly change the game in the marketplace. This model is 
increasingly proactive and anticipatory relative to customer needs. 

Customer focus defines this evolution for IBM Research strategy, while at the same time, the 
division has balanced its enduring commitments to basic research. Simultaneously with the 
evolution of the research mission, the nature of IBM has evolved so that the proportion of 
hardware and software, and services has changed to one where, today, services is the largest and 
fastest growing single component of the company. It is clear that as the services sector grows, 
IBM research will find itself called upon to provided innovation and technology leadership for 
the services sector. 

Strategic Processes for Project Selection 

The Research Division management is charged with positioning the research agenda and 
managing its portfolio so that the activities of the division remain vital to IBM’s business 
objectives. The division has installed replicable, and reliable processes that facilitate a division- 
wide strategic plan, while also retaining significant individual incentive and freedom to innovate 
and excel. The next few paragraphs describe these processes. 

• Global Technology Outlook. The capstone process is the IBM Research Global Technology 
Outlook. This is a division-wide effort to identify, track, and prioritize technology trends. It 
is produced annually. The purpose of the forecast is to identify technology areas where 
research or advanced concept demonstrations would be vital to IBM’s business interests. 

• Strategic Assessment. In light of the Global Technology Outlook, and other inputs, a 
management and strategy group defines and updates a multi-year Divisional strategy. 
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• Fall Plan. Each year, a fall planning process translates the strategic documents down to 
departmental and project levels, setting agendas and programs for the next calendar year. 

• Execution and Tailoring. The projects that comprise the total fall plan are executed in ways 
that encourage continuous refinement, self-assessments, and opportunistic mid-course 
corrections. Project execution must balance between pursuit of new opportunity and delivery 
of expected outcomes. Some Research projects are linked with product lab development 
schedules. Others are linked with external customer constraints by requirements, cost, or 
schedule. Many projects are driven by time-to-market imperatives. Projects may be of short, 
multi-year, or continuous duration. For example, IBM research has long-standing groups that 
support the DB2 database engine components, the General Parallel File System, and speech 
recognition. 

• Personal Business Commitments and Measurement. Every IBM employee makes a 
performance contract with his or her immediate manager regarding accomplishments for the 
coming year. These commitments, which for researchers, will normally align with projects, 
form the basis for annual measurements, which in turn are the basis for advancement and 
variable pay (a bonus system based on the division’s total performance for the year.) 

Personal Business Commitments are assessed not simply on technical or professional 
achievement, but also on market impact, customer satisfaction, and contributions to IBM 
business success. 

The combination of a customer-focused divisional strategy, and a demanding, incentivized 

measurement system drives technology infusion, because the entire annual cycle is serving vital 

IBM interests. 

Technology Insertion 

A second set of Research Division Processes is in place for bringing technology from the labs 

into the marketplace. Three approaches that are commonly used follow: 

• End-to-End Lifecycle Partnerships. Certain key software products have a continuing 
relationship with the Research Division. Two examples are the DB2 Database engine and the 
General Parallel File System. In these cases the product owners and the research division 
from an enduring team where advanced development, and leap-ahead technical approaches 
are undertaken by Research in concert with the product owners marketing channels, and 
solution providers. 

• Handoffs, Spinoffs, and Licensing. The division is continually seeking paths to market for 
research products. When a handoff to a marketing or product division occurs, it usually has 
been anticipated from the start. There are two interesting variants of technology handoffs that 
the division has utilized. One is to license the intellectual property, leaving market risk to the 
licensee. A second is to spin off a new company based on a technology or advanced service. 
IBM’s patent server, originally a project focused around building high performance web 
sites, turned out to be viable as the foundation of a commercial venture, called Delphion. 

• Push into Infrastructure. Many IBM Research contributions have been moved into a shared 
computing infrastructure. This is particularly true for technologies that contribute to the 
growth and refinement of the World Wide Web, Java, and XML frameworks. Improving 
infrastructure helps drive markets and create new opportunities for line-of-business 
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applications. In general, enriching infrastructure decreases complexity and costs of various 
line-of-business applications, and allows applications to be more responsive and resilient 
relative to specific customer needs. 

In summary, the IBM Research Division incorporates an agile, responsive, continually refined 
planning process to select projects, emphasizes working directly with customers over the entire 
life of a project, and has multiple paradigms for maturing and transferring research products. The 
system in support of IBM vital business interests has built-in incentives for the staff, and is 
harmonized with the other basic research mission of IBM Research through a collegial, open 
intellectual environment. 

5.4.3 Comparison with the NASA Advanced Information Technology Program 

The following comparisons are based on the author’s interactions with NASA staff during the IT 
assessment workshops. NASA OSS IT and CBM Research both have dual missions: fundamental 
research and applied research that is in support of the enterprise’s vital interests. 

In IBM’s case, the focus is on its commercial customers, and that focus is systemically resolved 
by customer segmentation on the one hand, and IBM’s lines of business on the other. It seems 
that OSS IT also has a customer segmentation, based roughly on mission planning, launch, and 
flight operations on the one hand, and the scientific community of interest surrounding each 
mission on the other. Accordingly, a customer-focused IT strategy can be more thoroughly 
matured and institutionalized, without compromising OSS long-range basic research interests. 

In the next section, I will develop this idea in one direction suggested by an alignment with one 
of IBM Research’s technology maturation paradigms. 

5.4.4 Perspective on NASA Technology Maturation 

Because each NASA mission is unique, it is not surprising to find that the technology in support 
of a mission is vertically integrated. This does not exclude reuse, but the mission plan necessarily 
requires extensive tailoring and mission-specific hardware and software engineering. OSS IT 
products will provide segments to the mission integrator. Academia, contractors, and other 
government sources will provide other segments. 

If multiple vertically-integrated missions are considered, it is apparent that horizontal threads or 
layers of commonality can be perceived. This leads directly to the concept of a shared IT 
infrastructure spanning many missions, where certain commonality and reuse can be exploited at 
lower layers, and mission-specific applications can be built on a common infrastructure. 

This observation connects most directly with the third of the technology maturation paradigms 
discussed for IBM Research, namely pushing innovation into a common infrastructure to 
increase the value and decrease the complexity of mission-specific applications. 

Such emphasis on mission infrastructure and common components is found in the November 
2000 OSS Strategic Plan (pp. 18 and 19). Although the plan discusses technology in general, it 
applies to IT. In particular it defines three objectives: 
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1. Acquire new technology and approaches 

2. Validate new technologies in space 

3. Apply and transfer technology. 

These objectives are resolved to activities that express both mission focus and visionary or 
anticipatory research, very like the IBM Research Division’s twin objectives of performing 
research that is vital for the business and achieving distinction in basic research. The discussion 
of the strategic activities in the OSS plan brings out practical approaches very much like the 
maturation and continuous partnering approaches used in IBM Research Division project 
selection and execution. 

5.4.5 Analysis of the NASA IT Assessment 

The IT assessment is not unlike periodic corporate re-examination of goals, wants, and needs. In 
addition to the previous observations that bring out the idea of a possible focus on mission 
infrastructure, the following additional observations arise. 

• NASA faces the challenge of being customer-focused in a situation where the Federal 
acquisition process modifies the direct, competitive marketplace in which a commercial 
enterprise operates. On the other hand the acquisition process can be tailored, especially in 
the concept exploration phase of new missions, to provide a structured opportunity for NASA 
to try new approaches initially in parallel and in competition with established approaches. 

• NASA technologies, especially in support of scientific collaboration, appear to be a broader 
use within the Government, and intra-govemmental partnering may provide greater payoff 
for IT. 

• IT pervades everything NASA does and every aspect of a mission, supporting stratified, 
horizontal integration models. 

• NASA’s overarching requirement for reliable software is clearly of commercial interest, and 
OSS IT already is positioned as a pillar of excellence in this area. 

• NASA’s scientific data customers also are driving fundamental work in distributed 
supercomputing, which is also clearly of commercial interest. 

• There are numerous IBM technologies, including microelectronics and hardware, that have 
prima facie applicability to OSS mission applications and to a general mission infrastructure. 
OSS is invited to pursue the possibilities of more detailed collaborations with IBM though 
the appropriate channels. 

In conclusion, the position of NASA OSS IT within the NASA enterprise resembles in several 
relevant respects the position of the Research Division inside IBM, and as in IBM, there are 
numerous opportunities for partnered approaches to IT projects. Jointly conceived and executed 
projects are favored by the Division, and several success paths for them have been outlined in 
this report. Customer focus dominates the IBM approach to applied research. A corresponding 
methodology, including institutionalized, replicable process for selection and management of 
projects, based on mission partners and mission focus is applicable to OSS. As observed in 
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Section 3 of this report, IBM and OSS formulate very similar strategic objectives, and it appears 

that mutual exploration of management approaches to successfully executing such similar 

strategies might be useful to each organization. 

5.4.6 Summary of IBM IT Research Program 

• Research Division management is charged with positioning its research agenda and 

managing its portfolio so activities remain vital to IBM’s business objectives. 

• IBM has a process in place that facilitate a division-wide strategic plan, while retaining 

innovation: 

— Global Technology Outlook- identify, track and prioritize technology trends and is 
produced annually. 

— Strategic assessment- using the above document a management and strategy group 
defines and updates a multiyear strategy. 

— Fall Plan- Each year, a fall planning process translates the strategic document down to 
project levels setting program for next year. 

— Execution and tailoring - Projects are executed in ways that gives continuous 
refinements, self-assessments, etc. 

• Additional processes 

— End-to-end lifecycle partnerships - a number of key product have a continuing 
relationship with research. 

— Handoffs, spin-offs and licensing - Seeking paths to market research. Here someone else 
assumes the develop risk. 

— Push into Infrastructure - research is moved into a shared computing infrastructure 
lessens the risk and allows application to be more responsive to specific customer needs. 

• IBM’s perspective on NASA IT assessment: 

— Technology is vertically integrated (each mission). 

— May want to look for horizontal threads or layers of commonality leading to possible 
shared IT infrastructure (spanning many missions). 

• Intra-govemmental partnering may provide greater payoff for IT. 

• Some of NASA’s IT research is driving commercial interest, e.g., 

— EBM has great interest in NASA’s unique expertise in reliable software. 

— Science analysis drives distributed supercomputing (clear commercial interest). 

• IT within NASA is pervasive, which could support a horizontal integration model. 

• OSS needs an institutionalized, replicable process for selection and management of projects, 

based on mission partners and mission focus. 
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5.5 Perspective from Academia (CMU, USC) 

5.5.1 University Research in Information Technology 

Success of the diverse missions of the NASA Space Science Enterprise depends on the effective 
and aggressive use of information technology. The Space Science missions have specialized and 
highly challenging requirements. In order to meet their objectives. Space Science missions 
require development of highly innovative and dependable IT solutions, and these generally 
involve highly demanding custom development efforts, careful incorporation off-the-shelf 
information technologies, and significant attention to management of the engineering and 
certification processes. 

In the paragraphs below, we briefly summarize some of the core challenges in information 
technology that must be addressed in order for NASA Space Science to effectively undertake 
future missions. We then examine the process by which these technology challenges are 
addressed, broadly speaking, and the particular role of universities in addressing them. We then 
consider opportunities for NASA in engaging university researchers to accelerate both the 
advancement of these technologies areas and the enhancement of NASA’s ability to assimilate 
the results of this effort. 

5.5.2 Space Science Information Technology Needs 

A particularly demanding sector of requirements relates to the various facets of reliability, 
construed broadly. In the absence of positive assurance of reliability for information technology 
subsystems, missions cannot launch. Because software is often used to embody the most 
complex algorithms and decision elements of systems, there can be great complexity and 
difficulty in developing the models needed to rigorously describe and analyze requirements. In 
addition, there can be significant difficulties in analysis and testing of implementations to ensure 
compliance: How can complete coverage be assured? How can asynchronous systems be tested? 
How can the testsets themselves be validated? The challenge is further complicated by the fact 
that information technology subsystems are themselves frequently used as a means to implement 
algorithms for detecting and responding to faults in other, physical, system elements. 

Another demanding area of requirements is related to system autonomy. Space Science 
missions, in particular, often require traversal of huge distances, and the resulting 
communications latencies (or shadowing) may preclude positioning decision capability entirely 
on the ground. Autonomy meshes with reliability: How can autonomy be achieved in a way that 
both reduces the probability of mission failure and that does so in a way that this low probability 
of failure can be assured? Many of the challenges related to lifecycle and data management also 
mesh with reliability challenges: How can the development and management processes be 
streamlined while simultaneously enhancing reliability? 

\ 

Most information technology systems in space are distributed systems, with multiple 
independent computing entities communicating with each other. Policies of determinism or 
strict master-slave communication patterns can facilitate modeling and assurance, and these 
policies are often adopted on this basis. But these policies can also be overly rigid from the 
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standpoint of design and flexibility, and can compromise the ability to deliver advanced 
capabilities, particularly those related to autonomy and (perhaps ironically) reliability. More 
aggressive approaches are needed in order to provide sufficient levels of reliability assurance for 
distributed systems that employ asynchronous techniques in order improve performance, 
capability, or robustness. 

One of the greatest areas of challenge in information technology is where people and computers 
meet, both in human-in-the-loop operations and in the processes of design and modeling. In 
operations: what are appropriate models for processes in which people are involved? How can 
reliability be enhanced in the design and validation of human interfaces? What are the 
architectural considerations in the design of effective human interfaces? How can human 
recognition capabilities be employed to design effective systems to manage and mine large 
amounts of scientific data? In design: what are the best design models to aid in understanding, 
for example of asynchronous activity, to ensure effective validation processes? 

An additional area of challenge is the development of information technology infrastructure that 
cross-cuts multiple Space Science missions. Indeed, cost-effectively increasing the number of 
missions in a mission area (such as Mars Exploration or Sun-Earth Connection) often means 
developing particular capabilities that can be broadly applicable across missions. This improves 
affordability and can lower overall program risk, but it also raises a number of challenging 
issues: How, for example, does the benefit of spreading development and sustenance costs over 
multiple missions trade with the potential costs arising from genericity, including performance 
costs and potential impact on ability to develop particular mission-specific capabilities? Another 
issue relates to reliability: Does genericity increase or decrease the difficulty of providing 
assurance of dependability, and how do these assurance costs distribute between generic and 
mission-specific cases? 

The point is, for Space Science, the extent the information technology challenge is magnified by 
the need to achieve increasingly aggressive functionalities, particularly relating to autonomous 
remote operation, while simultaneously improving reliability and reducing the cost and duration 
of engineering process. 

5.5.3 IT Innovation Sources 

NASA custom engineering is generally conducted by large commercial systems integrators and 
by major internal organizations and affiliated laboratories such as JPL. In addition, NASA 
acquires off-the-shelf technologies directly from major IT vendors. What is the role of 
universities in this picture? In order to consider this question, we must understand the means by 
which a large and specialized technology consumer such as NASA works with its suppliers to 
ensure its present and future needs will be met. When a major consumer such as the NASA 
Space Science Enterprise has demanding long-term technology requirements, it uses various 
mechanisms to engage with suppliers in order to ensure that the requirements can be feasibly 
addressed. This can include, for example, stimulating innovation, sponsoring development of 
underlying technologies, and developing measurement and evaluation methodologies. 

This collaboration involves more than the immediate NASA contractors and suppliers, since 
those contractors and suppliers themselves acquire technology from external sources. For 
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example, a mission control system will include off-the-shelf commercial hardware, in the form 
of workstations, servers, and network appliances, as well as commercial software components 
including operating systems, servers, file systems, graphical toolkits, networking components, 
and so on. In addition, there will be custom software components and glue code that enables the 
components to be integrated in a way that is flexible and adaptable to evolution in both 
requirements and underlying technologies. The design of the overall system is influenced by 
practices and tools to support the engineering and evaluation processes, as well as by the 
matching of potential future trajectories for both the mission control system and its constituent 
elements. Some of these trajectories, such as the custom code, may be under the direct control of 
NASA and the prime contractor. Other trajectories can only be influenced, however, because the 
customer communities are much broader; these trajectories include, for example, the evolution of 
constituent components and the standards according to which they are interconnected. 

NASA (and other mission agencies) long ago recognized that in order to effectively achieve the 
desired stimulus over the long term, they must work with multiple participants in this supply 
chain of components and technologies. This recognition is evident in the structure of 
participation in the broader IT community by NASA Space Science as well as other enterprises. 
Indeed, this is similar to the model long established at the Department of Defense, which 
includes DARPA, the Military Laboratories, and numerous other organizations. 

In order to achieve a particular stimulus, for example related to the development of autonomous 
systems, appropriate points of leverage must be identified in this technology supply chain. It is 
well documented in numerous studies of organizations such as the National Research Council, 
the National Science Foundation, and the President’s Information Technology Advisory 
Committee, as well as in privately developed reports, that federally funded academic research in 
information technology historically has been a principal leverage point with respect to 
innovation. The greatest direct influence of that innovation is on information technology 
vendors and end users. Integrators are also profoundly affected by this research activity, though 
through routes that are more indirect. These reports also provide evidence that, due to market 
incentives and other factors, research in universities and other publicly-funded laboratories will 
continue to be the major factor in long-term innovation and improvement of capability in 
information technology. 

The Department of Defense, for example, develops its most technologically aggressive concepts 
by engaging university and laboratory research teams. If the concepts have promise and the risks 
of further development and scale-up are acceptable, then the DoD will stimulate collaboration 
among those research teams and commercial organizations. The DoD invests in the commercial 
participation in order to buy down the risk of their committing resources and developing 
underlying technological infrastructure, until a market can be established. 

NASA manages in a similar way, stimulating appropriate collaborations in order to accelerate the 
transition of promising technologies to the point where they can be evaluated or applied in 
mission contexts. Indeed, the Technology Readiness Level gauge provides a management device 
to track progress in this maturation process. 
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5.5.4 The University Role in IT Innovation 

It is noted in the report of the President’s Information Technology Advisory Committee (PIT AC) 
that the IT industry expends the bulk of its resources, both financial and human, on rapidly 
bringing products to market. The retum-on-investment calculations made in industry generally 
preclude innovations that are fundamentally long-term in character or that have broad and non- 
specific impact. These include, for example, development of engineering practices that may lead 
to across-the-board improvements in reliability, or level of achievable autonomous capability, or 
in development of distributed systems, etc. This means that an assumption that industry will do it 
may, for broad areas of IT challenge, be incorrect, despite that seemingly rapid pace of industrial 
development. Universities and other research laboratories have a critical role in addressing these 
kinds of challenges, and in this regard their most natural alliance is with the mission 
organizations at the "top of the food chain" such as the NASA Enterprises. This is because it is 
in these organizations that the unmet needs are identified and best understood. 

The IT-related innovation undertaken in universities may yield intellectual property that can be 
packaged, protected, and marketed. But more often, perhaps, the results are of a form in which 
the impact diffuses broadly into the technical community, and cannot be confined to a single 
sponsoring organization. In this latter case, it may be difficult for individual companies to make 
the case for investment in a basic technology, since the value obtained may spread widely - 
including to competing companies - and may possibly generate market uncertainty. Examples 
of such basic technologies include advances in the basic concepts of algorithm analysis, 
performance estimation and measurement techniques, programming language foundations, and 
the like. These areas are fundamental and of broad interest and long-term impact, but there is 
relatively little near-term competitive advantage for particular technical results to kept 
proprietary. This being said, many large vendors do invest in these areas, but often on a 
secondary rationale, for example to maintain a collaborative connection with a research group or 
to have closer access to educational programs and the personnel pipeline. The effect is that there 
are considerable collaborative relationships between basic researchers in universities and their 
counterparts in vendor organizations. 

It is also important to note that when university researchers do develop protectable technologies, 
they can follow several possible routes to impact, most of which entail moving into the 
marketplace. One of the most common pathways, even in difficult economic times, is the 
creation of start-up companies that provide vehicles for packaging and proving a technology, and 
also evaluating the underlying value proposition in the marketplace. Successful start-up 
companies may be acquired by vendors or, less often, grow into vendors themselves. The vendor 
thus acquires the packaged intellectual property, as well as the experience, validation, and 
contacts with the early adopter customers. Another route is for the intellectual property to be 
packaged and marketed directly to vendors by a university. 

Technology sources for system integrators and consultant organizations are generally vendors, 
and less often original innovators. Competitive advantage for an integrator often derives from 
predictability, risk management, and process. For this reason, integrators have been less likely, 
in the present environment, to develop close alliances with university and laboratory-based 
innovators. 
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Because of its long-term impact, often with broad socio-economic consequences, university 
research in information technology is primarily federally funded. Fundamental, exploratory, and 
generic research topics are typically addressed through sponsorship of the National Science 
Foundation. Such topics include fundamental algorithms, programming language foundations, 
new operating system concepts, basic research in networking and distributed computing 
methodologies, and many others. Mission agencies, on the other hand, must address particular 
technical challenges and to emphasized coupling innovation with validation and transition. Their 
research sponsorship, while potentially of long horizon, is generally focused around identifiable 
mission challenges. 

For example, DoD is a major sponsor of research in computer and network security. But other 
agencies also sponsor research in computer security, and there is considerable variance of 
horizon and technical focus. For example, in recent years DoD has emphasized detection and 
remediation over prevention. Because there are communities of shared expertise and interest, 
individual agencies may take leadership in particular technical areas, even when other agencies 
have a stake. On the other hand, multiple agencies are involved in areas such as networking, 
high performance parallel algorithms, and real-time operating systems, for example. This 
diversity approach can have value in affording a mixed strategy for technical areas not well 
mapped, because a diversity of potential approaches can be taken to problem identification and 
solution development. Nonetheless, it is appropriate for some critical areas to explicitly identify 
a national lead agency. 

It is important to note that universities are involved in nearly all areas of information technology 
research. Their critical position in the pipelines of both personnel and technologies forces them 
to address the full range of technical challenges and opportunities. The National Science 
Foundation information technology research portfolio covers nearly all areas of information 
technology research. 

In addition, university researchers have built-in incentives to disseminate ideas and have them 
evaluated and appreciated by colleagues, since these are principal stepping stones to academic 
career advancement. This means that, roughly speaking, university research offers a built-in 
quality assurance mechanism. The principal drawback of this mechanism is that it may create 
incentives for researchers to avoid bold thinking and risky research directions that may not 
harmonize with conventional wisdom in a research community. 

One area of particular challenge for university researchers is dealing with issues related to scale 
in engineering and experimentation. It can be difficult in a laboratory environment to replicate 
conditions of industry. For example, university researchers may find it difficult to gain access to 
a large and active industrial database of software source code, because that code may be the 
principal embodiment of valuable intellectual property or because of security concerns. 

Finally, it is important to note that there are considerable variations in research management 
style among universities. Some university departments excel in theoretical single-investigator 
research, while others create incentives and offer infrastructure for collaborative efforts that 
involve experimental engineering. 
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5.5.5 Universities and NASA IT Research 

In addition to IT efforts focused on the particular needs of an individual mission, NASA 
undertakes a range of information technology research programs that are designed to address 
multi-mission challenges of pressing concern in the NASA enterprises. NASA-wide IT research 
programs enable focusing of resources in order to develop communities of competency within 
the NASA IT research organization and within the a ffi liated research co mmu nities. Members of 
these communities are expert in the particular technical areas that may contribute to addressing 
the challenge, and they are also familiar with NASA mission challenges that motivate the IT 
research program. This familiarity is gained through interaction with NASA personnel and 
exposure to NASA problems. It can enable researchers to consider NASA challenges at the 
earliest stages of their work, and it also incentivizes them to employ NASA experience and 
artifacts in validating concepts as they are developed. This kind of approach can result in 
accelerating the process of advancement along the TRL scale. 

When university researchers develop a result that has the potential to contribute to meeting a 
NASA mission requirement, NASA managers can then take various kinds of actions to inject 
that result into NASA’s information technology supply chain, as described above. This can 
mean, for example, working with critical vendor organizations, collaborating with NASA 
engineering groups, engaging with integrators, participating in requirements formulation, 
consulting in development of evaluation methodologies, or undertaking other activity as 
appropriate to the particular technical result. 

The most appropriate route of technology transition from researcher to NASA may be indirect. 
Consider, for example, several of the technologies for lightweight formal methods, such as 
model checking. The earliest transitions of technical results in model checking were to hardware 
vendors. This means that the chips acquired by NASA, its vendors, and integrators are likely to 
have more reliable designs. The technology transition connection between NASA and the 
researcher is thus indirect. But it is nonetheless efficient and leveraged, in the sense that the chip 
vendor is driven for competitive reasons to have reliable designs, and the costs of achieving that 
reliability are shared throughout the market for that chip. NASA investment in the underlying 
technologies accelerates the ability of a vendor to deliver higher levels of reliability in designs. 

If NASA developed a chip independently (as is often necessarily the case) then NASA would 
have to bear the entire cost. Another example of the indirection of the route is in the area of 
advanced testing strategies. A university researcher successfully developing new testing 
techniques may most effectively transition them to NASA through a tool vendor. The vendor 
thus bears the costs of packaging the techniques in a robust and usable form, and may have 
competitive incentives to bring the capability to market quickly. 

5.5.6 Summary of Academia Perspective 

• In order to meet their objectives, Space Science missions require development of highly 

innovative and dependable IT solutions, and these generally involve: 

- Highly demanding custom development efforts 

- Careful incorporation off-the-shelf information technologies 

- Significant attention to management of the engineering and certification processes 
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• Particularly demanding requirement areas: 

— Reliability 

— Autonomy (assumes significant need for reliability) 

— Where people and computers meet, both in human-in-the-loop operations and in the 
processes of design and modeling 

• Several approaches to development are used for the long term 

— DoD employs university and lab research teams, then stimulates transfer to commercial 
organizations of promising concepts 

— NASA works with universities and vendors to transition technology to missions 

• IT industry spends most of its resources bringing products to market rapidly (little long-term 
investments) 

— Thus not necessarily true that industry will do it 

— Similarly, if technology cannot be owned, industry may reduce investment 

• University IT research is primarily federally funded (e.g., NSF) 

• Sometimes several agencies are involved (e.g., computer/network security). 
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6. Implementation/Infusion Issues 

6.1 ARC Perspective on Technology Infusion 

6.1.1 Background 

Technology transfer is a difficult and complex process for any organization. Whether you are 
talking about IBM, Intel, Microsoft or the Department of Defense, creating a process that bridges 
the gap between research and the eventual productization of the ideas to impact an organization 
is challenging. To suggest NASA or more specifically the information technology investment 
within NASA has a unique problem in this area is naive. Within private industry, one has to look 
no further than one has to look no further than the famed Xerox Palo Alto Research Center for an 
example of a vibrant research environment that had minimal impact on the funding organization 
despite the vast array of technological advances that occurred within the organization. The Palo 
Alto Research Center is a great example of the potential benefits that can be developed through a 
vibrant research program. However, it is also an example of how an ineffective strategy for 
harnessing these advances can result in less of an impact on the organization. At the same time, it 
also highlights how long it often takes for technological advancement to be widely accepted. The 
basic concept of a mouse and icon interface for a personal computer was demonstrated at the 
Palo Alto Research Center over 10 years before it came to market as part of the Macintosh 
operating system. Then it took another 10 years before it became common place on most desktop 
computers as part of Windows. Thus, in one of the most aggressive industries in terms of 
technology adoption, it took almost 20 years for a basic advance to have the broad impact that 
was first envisioned when the ideas were developed. Within NASA, electric propulsion took 
almost 20 years from the development of many of the initial concepts before the DS-1 flight 
experiment demonstrated the potential impact of this technology. 

Of course, the difficulty of this process is all the more reason to apply a focused and concerted 
effort to try and address many of the challenges that exist. While it is challenging, many 
organizations have successfully addressed this challenge to transition fundamental ideas into a 
wide array of products that are in common use today. In most cases, successful transition of 
technology occurs through a variety of paths and processes. There is no one shoe that fits in all 
cases. In general, however, organizations that due well do so due to a clear and well defined 
process that helps to bridge the inherent gap along with an organizational commitment to bring 
these two sides together. If NASA is to accomplish many of the missions that it has envisioned 
for the future, it is critical for the organization to understand and manage this process. Within 
NASA, today’s problem is all the more pronounced due to both fiscal restraints as well as the 
focus on faster, better, cheaper missions. This is because it becomes much harder for any one 
mission to accept the risk and cost of adopting new technology. As a result, it is easy for the 
organization to end up in a tragedy of the commons in which the incentive is not sufficient for 
any one mission to adopt technology and as a result all of the missions suffer in the long run. 

To gain a deeper understanding of the problem and to make some concrete suggestions regarding 
how to address the problem, this write-up will go through a number of steps: 

1. Problem identification - What makes this problem so difficult? 
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2. Example successes - What are some examples where the process has worked? 

3. Existing process - Drawing from these examples, what is a description of the current process. 

4. Lessons learned - What are the shortcomings of these processes? 

5. Recommendations - What can be done to make the process work better? 

6. Organizational structure - What is the impact of the top-level organizational structure on 
technology transfer. 

6.1.2 Problem Identification 

The general problem of technology transfer is actually quite simple to understand. An inherent 
tension exists between the basic ideas that have potentially broad applicability and the 
maturation and instantiation of these ideas into a specific system or product that meets a clear 
need of a mission or customer. Furthermore, the most instantiated products only make limited 
use of technology. This is especially the case in the area of software systems. Thus, technology is 
only 10% to 20% of the solution. The rest of the solution requires good systems and software 
engineering development. This ratio leads to another aspect of the problem a nd th at is the 
interests and objectives of the individuals who are involved in this process. Researchers often 
choose to focus their energies on broad strategic impact and often do not have the desire or the 
skill required to take these ideas and apply them within an integrated system. Similarly, mission 
engineers are often focused on choosing a path that minimizes their risk on a particular project. 
Thus, they are often not motivated to adopt new technology that increases risk especially when 
they do not understand that technology in depth and are unsure what is required to mature this 
technology so that it can be used within a larger system concept. 

This characterization, however, is overly simplistic. In the end, both communities really share a 
common goal. Most researchers (at least the good ones) care deeply about the eventual impact of 
the ideas that they are developing. Similarly, people focused on a particular project would love to 
absorb innovations that provide greater capabilities to them while also paving the way for 
increased capabilities in the future. 

Addressing this problem while leveraging the inherent desire of both sides to deliver increased 
capabilities leads to the following key challenges: 

• Challenge 1 — Matchmaking: How do you ensure that the technology being developed is 
meeting the needs of future missions and how do you connect a given mission with the 
appropriate technology that might meet their need? If technologies being developed are not 
meeting the key needs of a mission, then all other processes to help transition the technology 
are doomed to failure. 

• Challenge 2 — Broadening horizons: How do you get missions to consider classes mission 
concepts that are enabled by new technology? 

• Challenge 3 — Maturation and motivation: How do you motivate both the technologists and 
the end customers to meet in the middle so that technologies can be matured and integrated 
into larger system concepts. 
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6.1.3 Example of Success 

A number of examples exist where technology has been effectively transferred. To adequately 
address this topic, a much more in depth analysis of these and other successes as well as failures 
should be performed to understand what works and what doesn’t. This write-up simply identifies 
a small number of successful examples so that we can draw on some of the lessons learned: 

The Remote Agent Experiment demonstrated an integrated autonomy architecture as part of the 
New Millennium Deep Space One mission. This example is quite complex with many different 
phases of the project. It is both an example of a successful technology transfer activity as well as 
an example of some of the pitfalls that can be encountered. This experiment is well documented 
and there is not ample room within this document to analyze this experiment. Instead, I will 
identify a number of key features of the project that were critical to the eventual demonstration. 
Note that Remote Agent is a good example of a demonstration of what I will call system-level 
technology. By this, I mean that it is technology that is intimately intertwined into the system. In 
other words, the technology can not be viewed as a single module with well defined, simple and 
clearly understood interfaces into the rest of the system. Maturation and injection of system-level 
technology is particularly challenging. 

• Lesson 1: Technology transfer is a full-contact sport. The successful demonstration of the 
technology required lots of hard work and partemering between people that understand the 
mission requirements and the technologists. Close day-to-day contact was required to 
successfully achieve the mission goals. In fact, one could say that one of the mistakes early 
on in the process was the inadequate integration between the flight software team and the 
autonomy technology team. 

• Lesson 2: Technology transfer often requires an integrated project with shared objectives and 
a single lead.. The DS1 team was an integrated team that was working toward a fixed project 
schedule. Both technologists and mission engineers had shared objectives with a single 
project leader. 

• Lesson 3: Full commitment is required on both sides of the team. During the flight 
experiment, various personnel came and went. However, there was a core group that 
remained throughout the project. The eventual success of the experiment depended upon the 
commitment of these personnel. 

6.1.4 Existing Process 

The example provided in the previous section provides anecdotal evidence of the type of success 
that has occurred in transferring IT technology into missions. While each of these cases are 
slightly different, in general, they can be used to help identify the existing process that is used for 
technology transfer. In general, there are three phases of the existing process: 

Step 1: Technology portfolio selection - This phase of the process focuses on the selection of the 
research tasks that are funded by the various research programs. Both the IS program and the 
Cross Enterprise Technology Development Program performed this task through a staged 
process as follows: 

1. Workshops/meetings with Enterprise and Center reps to identify their needs 
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2. Initial call for proposals in areas that match the enterprise needs 

3. Quality review of the proposed or directed activities 

4. Relevancy review by Enterprise representatives to help rank and select proposals. 

While this process has not always been followed religiously, in general the portfolio selection is 
done through coordination with people who can represent the broad class of missions being 
considered by the enterprises. Note, however, that often the individuals who participate in these 
activities may not have the breadth to truly represent all of the needs of a particular enterprise. 
Since this phase depends upon personal communication, the biases and interests of the 
participants can skew the process. 

Step 2: Insertion opportunity identification - This phase has occurred almost entirely through 
informal interaction and communication and people and programs. Thus, this phase has not had a 
well-defined structure that helps to bridge the gap between technologists and missions. Instead, 
this gap is bridged in isolated instances due to either the clear need of a mission for technology 
or through continued communication between the provider and people who are working with the 
consumer of the technology. For example, Remote Agent occurred because pressure was applied 
to the management at Ames and of the CETDP program to demonstrate the relevance of the 
technology that had been developed over the years. Similarly, the MER technology transition is 
occurring due to communication between The Mars Program and Ames research center. 

Step 3: Technology insertion - In almost every case listed above, the maturation of the 
technology and eventual insertion occurred due to the participation of both the technologists and 
the end consumer in a coordinated project. The only way to hand off technology in the IT arena 
is usually through very close collaboration and coordination. 

6.1.5 Problems With the Existing Process 

While the existing process has worked in a number of cases, there are a number of shortcomings 
that must be addressed if we are to be more successful in creating a broad adoption of advanced 
IT technology within the agency. Some suggestions for improving the process are provided 
below: 

6.1.6 Motivating Adoption of Innovation 

One of the biggest problems within NASA for technology infusion is the existing mechanisms by 
which programs are managed. While there is good reason for this type of management, the result 
is sub-optimal in terms of technology adoption. In industry, technology adoption by the business 
units of a large corporation (e.g., IBM) from the organizations research divisions occurs because 
the product divisions are required to innovate if they are to stay competitive in the rapidly 
changing IT marketplace. Thus, an appropriate motto in many of these organizations might be 
innovate or die. 

Unfortunately within today’s NASA, the opposite is true. To understand why this is, lets look at 
the four key ways in which IT technology can impact a mission: mission enabling (without the 
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technology, the mission cannot be performed), cost reduction, risk reduction, or increased 
science return. Obviously, in the first case, a mission is adequately motivated to adopt new 
technology. Mars ’09 is a good example of a mission of this class. The other three ways in which 
IT can impact a mission; however, lead to problems. This is due to the fact that any increase in 
risk is often shunned by the mission. This is because in today’s fiscally restrained world, each 
individual mission is under tight constraints to deliver the mission with the available resources 
which are often limited. If a mission fails to meet this requirement, often the mission does not 
ever get off the ground. Good examples of this can be seen in the resent demise of many of the 
X-vehicles that have been developed by NASA. Of course, canceling a mission or even worse 
losing a mission is the worst possible scenario for a mission manager. As a result, the managers 
objective function is highly non-linear (in fact it is a step function) when you consider the impact 
of loosing the mission or being canceled. Thus, if a technology can increase science by 50%, 
often this benefit is not adequate to justify the inherent risk that the project manager is accepting. 
Note that risk is not just relevant once the mission is deployed. Risk is also an important element 
when it comes to cost and schedule. In the past, a mission manager could accept this risk since 
there was some flexibility in terms of cost when push came to shove. Thus, for increased science 
return some risk would be accepted since if the technology proved more problematic than 
expected the mission manager could always resort to other resources before canceling the 
mission or flying the mission without having sufficiently eliminated some of the risk within the 
mission. 

To put this argument more succinctly, the value of the science returned for a mission rapidly 
decreases when viewed in comparison to any increased risk for the mission. 

Of course, the problem with this equation is that the mission manager is making a decision that 
optimizes his reward but this results in a potentially sub-optimal decision for the theme, 
enterprise or agency. In other words, while adopting technology in one mission might not be 
warranted by that single mission, it might be warranted due to the potential benefits provided to 
other missions that are in the pipeline. 

To address this problem, it is absolutely critical to find creative ways to motivate missions to act 
in a manner that is optimal for the overall agency/enterprise when it comes to adopting new 
technology. To do this, however, it is necessary for the enterprise/agency to accept some of the 
risk of this adoption in terms of budget flexibility for the mission manager in case things do not 
work out as expected. 

6.1.7 Facilitating and Matchmaking 

In the process described above, this was the portion of the existing process that often leaves 
much to be desired. To facilitate technology insertion, it is absolutely critical to have a more well 
definted process in which the missions can find out about what technology is out there. 
Unfortunately, doing this through some data base or other static medium is doomed to failure. 
This type of interaction needs to occur through regular personal interaction along with a deeper 
understanding of the specific mission needs. 
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6.2 JPL Perspective on Technology Infusion 
6.2.1 Technology Infusion Models 

Historically, several models for technology infusion have been utilized or proposed at JPL. This 
section summarizes these various models. 

Over the Wall 

In this technology infusion model, there is no pre-defined infusion path. Prototypes of new 
technology-based capabilities are developed and declared mature by technologists. These 
capabilities are promoted via demonstrations and other marketing activities. Because there is no 
prior linking of developed capabilities to mission needs, mission users will pick up new 
technologies promoted in this fashion only when a compelling (typically fortuitous) fit exists 
with mission needs or a user side champion spontaneously appears. 

Onus on Technologists 

Within this technology infusion model, technologists are expected to champion their 
technologies and technology programs are expected to fund the further development and 
tailoring of technologies to accomplish mission use. This approach potentially compromises the 
generality of the solutions achieved in prototypes. There is also the risk of diffusing technology 
program activities away from the longer-term strategic investments. Finally, this model is not a 
good general model for infusion because only a few technologists will be motivated and suitable 
for this type of championing activity. 

Onus on Users 

Under this model, missions conduct their own technology development activities against their 
own identified needs. Rarely will technology products developed this way have generality 
beyond the identified need and potential for multi-mission use. Also, rarely will technology 
products developed this way utilize or reflect the state-of-the-art, because of natural (and 
justified) conservatism on the part of the missions. This approach works only when a project has 
a sufficiently large development budget to enable these internal investments. In general, projects 
are not funded at the level required to enable this technology infusion model in the current 
NASA environment. Historically, most technology infusion into flight projects has occurred 
within this model. 

The previous three infusion models have all appeared in JPL/NASA mission and program 
contexts, with different degrees of success. The following two models have begun to appear in 
part and are proposed as attempts to improve on prior successes. 

Shared Onus 

Under this proposed technology infusion model, there is shared responsibility for accomplishing 
infusion among the programs for technology development and missions. The goal is to 
coordinate different program activities to achieve coherence across the technology maturation 
lifecycle. For example, continuing funds for technologists may be made contingent on their 


204 




Chapter 6. Implementation/Infusion Issues 


O' 

u 

w 

w 


v_/ 




v=/ 


K-S 


V 

© 

s? 

KS 

u 

w 


having users signed up to accept and co-fund the further development and tailoring of agreed-on 
technology products. Focused technology programs may be created and chartered to fund the 
bridging development between technology prototyping and mission use. Projects themselves 
may have portions of their budgets set aside for the purpose of accomplishing the final stages of 
infusion. 

Peer-Level Coordination 

Within this proposed technology infusion model, the activities of technologists and mission users 
are coordinated closely throughout the technology maturity lifecycle. Specifically, mission- 
experienced users inform technologists which capabilities are needed, with the implication that if 
technologists deliver on those capabilities, those products will indeed be infused and used on 
missions. Technologists inform users what range of solutions at the state-of-the-art are within 
reach, and extend the possibilities for the set of capabilities that can be brought within the state- 
of-the-practice. Coordination starts from the earliest road-mapping activities and continues with 
iterative re-evaluation and re-targeting until development is complete and infusion is achieved. 

6.2.2 Assessment of Technology Infusion Models 

Provided here is an assessment of the merits and overall success of the various technology 
infusion models described above. 

• Over the wall. Success has been extremely hit-and-miss under this infusion model, which is 
really no model at all. Success is almost a random event, requiring the fortuitous, unplanned 
confluence of interest, need, and personalities. 

• Onus on technologists. The success of this infusion model also has been hit-and-miss. 
Success requires highly motivated technologists to pursue infusion relentlessly. Success 
within this relatively narrow model may also compromise long-term investment goals within 
technology programs. 

• Onus on users. This infusion model has been the most successful for achieving technology 
infusion for specific missions, but does not address long-term technology investment goals. 
This model is unsustainable in the current environment of significantly reduced project 
development budgets 

• Shared onus. This infusion model can be viewed as a top-down (programmatic) approach, 
addressing some of the flaws and gaps in previous approaches. There will be a significant 
programmatic challenge associated with coordinating activities and applying resources across 
basic technology programs, focused technology programs and projects, all for the purpose of 
maturing technology in different phases of the lifecycle, toward a shared goal of development 
and infusion 

• Peer-level coordination. This infusion model can be viewed as a bottom-up approach, 
addressing a complementary set of flaws and gaps in previous approaches. Experience 
shows that a key to coordination effectiveness is to achieve peer-level mutual respect. This 
happens naturally when the individuals involved are seen to be experts in their area who are 
capable of articulating their interests, priorities and goals. Once peer respect is achieved, 
motivation and determination become self-reinforcing, and the potential misunderstandings 
or even adversarial stances that occur under other infusion models can be swept aside. A 
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potential limiting factor under this infusion model is that mission and technology peers 
(workforce level) typically do not control resources. 

6.2.3 Recommendations for Technology Infusion 

• Adopt a combined shared onus / peer-level coordination technology infusion model. This 
combined model for technology infusion would include the best of the top-down and bottom- 
up approaches. In particular, both the program level and the workforce level considerations 
for success are addressed in such an aggregate approach. This model would appear to align 
all required resources and expertise to achieve infusion success. The key to success is to 
coordinate activities across the technology maturation lifecycle. 

• Create an explicit cross-apprenticing model for technologists and users. Some mission-side 
users of technologies and tools take an assignment on technology development teams, and 
some technologists take an assignment on mission development / delivery teams. There is 
long-term benefit in each community understanding and appreciating the contributions and 
challenges of the other community 

• Mission formulation teams populated by both technologists and users. The goal of the 
mission formulation teams should be to identify which capabilities are missing and which 
technologies are missing. User-side champions for new capabilities and specific 
technological approaches can emerge early and naturally as part of these interactions. These 
teams should meet often to keep the set of mission concepts fresh and informed by both the 
science/mission and technology viewpoints. These teams create products that become inputs 
to mission and technology road-mapping activities. 

• Mission and technology roadmaps should be jointly developed and owned. Mission 
roadmaps are traditionally owned by the theme technologists and the mission programs. 
Technology roadmaps are traditionally owned by the (basic and focused) technology 
programs. A more powerful approach is to conduct joint exercises to develop and cross-strap 
these roadmaps, especially with an eye to articulating technology infusion goals for near- and 
mid-term missions, to be jointly held and pursued by both types of programs. 

• Funded activities need to be coordinated. Again, the key is to usefully couple the funded 
activities in the technology programs and mission programs to jointly realize shared infusion 
goals, in a planned, progressive fashion. The initial maturation of a technology occurs within 
the technology program. When successful, there is up-front agreement that the technology 
will be taken forward, with appropriate follow-on activities funded to do so. If a focused 
technology program is the next context, that program now takes the lead to coordinate with 
the mission customer, with another up-front agreement on what the additional maturation 
goals are. When those goals are also successfully met, the relevant mission program funds 
the remaining adaptation/insertion activities to achieve final infusion. Rather than a series of 
handoffs, this approach describes a set of defined, coupled, progressive activities. Infusion 
may fail of course, but in this model there is commitment to proceed as long as success is in 
sight. 

• Dedicated technology infusion roles should be created. Because technology infusion is so 
hard, another ingredient for success can be the creation of specific roles dedicated to the 
prolonged task of achieving technology infusion. Technology programs should identify 
technology infusion engineers whose role is to initiate and track the early activities in a 


206 


Chapter 6. Implementation/Infusion Issues 


v./ 

w 






O 


: v' 
, ^ 






^7 

V 


1 V7 


' 

1 ^ 

v_/ 

w 

v> 

w 

V 

i ^ 


technology infusion cycle. Ideal candidates are technologists who have the relevant research 
background and have had experience leading development teams. Later in the lifecycle, 
technology infusion engineers should appear in the project context, and have the same status 
as system engineers on projects. Ideal candidates are those with delivery experience who are 
champions for the capability realized via the technology. These infusion engineers are part 
of a larger infusion team that exists across the technology and mission programs and the 
projects. 

6.2.4 Summary Lesson 

If there is a most important lesson to draw from evaluating successful and unsuccessful models 
for technology infusion, it is the following: Technology infusion activities must be characterized 
by continuous mission user and technologist representation and interaction throughout the 
technology maturity lifecycle. 

6.3 GSFC Perspective on Technology Infusion 

6.3.1 Technology Infusion Impediments 

Impediments to the successful infusion of new technologies into NASA mission systems fall into 
three main categories: technology provider shortcomings, technology user shortcomings, and 
technology infusion management shortcomings. This categorization is useful because it helps to 
focus the strategies needed to eliminate the impediments on the three major players in the 
technology infusion process. 

6.3.2 Technology Provider Shortcomings 

Technology Providers are technologists and R&D teams who identify, assess, evaluate, and 
prototype new and emerging technologies which may satisfy current or future needs of NASA 
technology users. 

• Understanding of Mission Needs. There is a huge gap of understanding of mission needs by 
technology producers and inadequate customer focus by the technology providers. 

Strategies- increase communications and regular on-going interactions between these two 
groups; co-locate teams; establish “liaisons” between technology provider community and 
end user communities; better utilize NASA Technology Inventory. 

• Communication with Users. There is inadequate ability by the technologists to communicate 
in terms meaningful to mission development teams/ target end users. Strategies- provide 
increased opportunities for the research community to interact with and work on a side-by- 
side basis with end users; appoint liaisons to serve as bridges between the two communities 
and to help each side understand the other and to describe the benefits the technology offers 
in context of user’s needs or requirements; promote dissemination of results of Enterprise 
technologists (e.g. OSS’s Technology Steering Group) to the technology provider 
community; proactively include target users on relevant reviews, demonstrations, etc, and 
seeking their feedback and concerns. 
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• Selection of Infusion Targets. There is inadequate or naive consideration of infusion targets 
and infusion opportunities by technologists. Strategies- require technology development and 
infusion plans earlier in the technology project lifecycle; establish technology infusion 
champions to proactively seek and facilitate successful technology evaluation and infusion; 
utilize Enterprise roadmaps and technology needs plans more actively. 

• Understanding of Operating Environment. There is unrealistic or incomplete understanding 
of the operating environment and the real problem by the technologists. Strategies- provide 
increased opportunities for the research community to interact with and work on a side-by- 
side basis with end users; co-locate teams; require technologists to identify target operating 
environment early in the technology lifecycle, understand the characteristics and limitations 
of it, and establish a technology maturation plan to address the challenges; involve end users 
early and often to specify performance requirements and operating environment issues and 
challenges. 

• Overconfidence in Technology Readiness. There is inadequate maturity or overconfidence 
of technology; inadequate testing or other means to insure reliable software. Strategies- 
provide shared responsibility and accountability for estimation of resources required for 
technology infusion and validation; encourage (and possibly require) interaction between 
technology providers and mission system developers to jointly assess the technology 
readiness and maturity plan; require technologist to specify technology’s performance and 
reliability. 

• Risk Evaluation. There is inadequate capability by technologist to identify and retire risks 
associated with technologies. Strategies- increase knowledge of risk management strategies 
for operational systems; establish liaisons between technologists and users; increase 
communications between these technology providers and prospective users; require 
technologists to delineate risks that must be retired before incorporation into operational 
systems; develop validation plan and validation success criteria with target user. 

6.3.3 Technology User Shortcomings 

Technology Users are mission formulation teams, mission development teams. Principal 

Investigator (PI) teams, mission and science operation teams, and mission science users. 

• Understanding of Technology Capabilities. There is a huge gap of understanding of 
technology capabilities by mission development teams/ target end users. Strategies- 
increased communications and regular on-going interactions between these two groups; co- 
locate teams; establish liaisons between technology provider community and end user 
communities; better utilize NASA Technology Inventory. 

• Awareness of Emerging Technologies. There is inadequate awareness and understanding of 
emerging technologies by early mission formulation teams, mission development teams, and 
prospective end users. Strategies- provide seminars and technology forums to expose the 
target user community to emerging and existing technologies and their functional 
capabilities; increase acceptance of the use of existing technologies for achieving functional 
requirements; involve technology experts early in the mission formulation process (including 
in mission design centers) for inputs on emerging and available technologies. 
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• Understanding of Systems Environment. There is a myopic viewpoint of the problem and 
solutions to address it; regressive adherence on existing operating environments, 
architectures, systems, and components and systems. Strategies- increased communications 
and regular on-going interactions between these two groups; co-locate teams; establish 
“liaisons” between technology provider community and end user communities; encourage 
open consideration of all solutions and emerging technologies. 

• Risk Evaluation. There is an unsubstantiated perception of risk by mission development 
teams/ target end users; Perception of risk associated with technologies by mission 
development teams / target end users. Strategies- establish liaisons between technologists 
and users; increase communications between these groups. 

6.3.4 Technology Infusion Management Shortcomings 

Technology Infusion Managers are responsible for technology infusion planning and budgeting; 

for obtaining the personnel, facilities, and evaluation resources needed for technology infusion 

efforts; and for establishing the communication channels needed for successful technology 

infusion. 

• Planning. There is inadequate, proactive planning for technology insertion. Strategies- use 
extended missions to validate technologies; host forums to communicate technology product 
capabilities; keep the NASA technology inventory up to date and inclusive of all NASA 
technologies under R&D; include technologists early in the mission lifecycle; proactively 
include target users/mission system developers on relevant reviews, demonstrations, etc, and 
seeking their feedback and concerns for technology infusion. 

• Openness to All Solutions. There is inadequate appreciation and funding for innovative 
application of existing technologies-intemally or externally developed-to meet existing 
technology challenges or to enhance current capabilities/systems. Brief description- priority 
often given to emerging, low-TRL, or “exciting” solutions over other more mundane or 
proven technologies by technologists; the opposite may hold true for the technology users 
community. Strategies- encourage full consideration of all technology solutions; increase 
information on existing and emerging technologies; increase use of NASA technology 
inventory. 

• Resources and Budgeting. There is inadequate resources and flight opportunities for 
validating and maturing technologies in realistic environments. Strategies- establish 
increased resources for the validation and infusion of technologies. 

• Communication. There is inadequate communication and interaction between technology 
researchers/R&D teams, infusion and maintenance teams, and end-users; Inadequate 
documentation of technology capabilities, software, and necessary documentation essential 
for the insertion and maintenance of software technologies. Strategies- require increased 
documentation of results and capabilities of technologies by technologists; encourage 
increased interaction between providers, users, and developers; emphasize joint collaborative 
efforts with parties from each side. 

• Cost Estimation. There is inaccurate cost estimations for the technology development, 
infusion and maintenance; Inadequate consideration of “full cost of ownership” of 
technology; gross underestimate of cost/effort for technology maturation, infusion, and 
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maintenance of technology. Brief description- all too often the technology providers don’t 
consider the complexity of the technology and the associated skills required to infuse a 
technology into an operational system and maintain it over the missions lifecycle. Strategies- 
encourage (require?) interaction between technology providers and mission system 
developers to jointly estimate the cost for technology development, infusion and maintenance 

6.4 Alliance Development Opportunities 

Some existing alliances were described in Sections 6.1 and 6.2 above (NSF and DARPA). 

Others were suggested in the remaining sections of Section 6. There is clearly much scope for 
coordinating IT research efforts among government agencies, but significantly increased 
planning and management would be required to make this effective. In particular, each agency 
has quite different mechanisms for Technology Infusion, and any proposed collaborative effort 
should address these issues first, since without defining a clear path to infusion within NASA, 
particularly for OSS missions, such collaboration is unlikely to be successful. 
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7. Recommendations 

7.1 Recommendations Reported in Executive Summary 

7.1.1 OSS User Group Perspective 

This section identifies the views of the IT user community with respect to each task and suggests 
recommendations. 

Objective 1. Perform a critical assessment of NASA’s planned information technology R&D 
and its relevance to future OSS missions. 

Finding l. A substantial portion of NASA’s current IT investment is relevant to future OSS 
missions and can be classified as follows: 

• Directly relevant to OSS missions/ infusion path defined. 

• Directly relevant to OSS missions/ infusion path uncertain. 

• Diffusely beneficial to OSS missions/ infusion path defined. 

• Diffusely beneficial to OSS missions/infusion path uncertain. 

• Not relevant to OSS missions. 

Much more work is necessary to categorize the current IT tasks sponsored by NASA into the 
classifications noted above. However, it is clear that only a small fraction of the IT products 
reviewed are directly relevant and seemingly ready for infusion. In addition, the majority of the 
relevant or beneficial IT R&D lacks a defined infusion path into OSS missions and/or lacks the 
mechanism or funding necessary to implement the infusion even when a customer is identified. 
Left unchanged, this will continue to severely discount the future value to OSS of even a well- 
aligned IT program. 

Recommendation. Relevance or alignment of the IT program must be viewed in the context of 
the difficulties presented by technology infusion. (More complete recommendations regarding 
infusion follow Objective 3 below.) 

Finding 2. There appear to be obvious and serious gaps between existing IT programs and 
mission needs in several areas, including processor technology, software reliability, and science 
data processing. And although OAT investments in IT have been, and are, significant, recent 
modifications to OSS programs have impacted the availability of technology funding for IT; for 
instance, IT for Exploration of the Solar System missions has been seriously impacted by FY02 
cutbacks in the Mars Technology Program, Outer Planet Technology and the Remote 
Experimentation and Exploration Program. 

Recommendation. Even with significant existing investments in IT, several IT areas may still 
require augmentations or other remediation in order to provide needed capabilities for future 
flight missions and to enable future applications such as autonomy. 

Finding 3. The bulk of NASA OSS-relevant IT is focused on planetary exploration. Certainly 
these demanding applications call for some of the most exotic IT and thus attract the interest of 
those on the cutting edge of research. Reinforcing this, the opportunities for infusion of IT into 
planetary missions may have been greater than in other mission areas. There is evidence that 
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non-planetary IT challenges are thought more mundane and less promising areas of research. 
Customers in other themes are viewed as more resistant to the benefits of IT infusion. 
Recommendation. IT R&D should serve the needs of each division in OSS. Development 
geared toward solving IT problems in Sun-Earth Connection (SEC) and Astronomy and Physics 
(ASO/SEU) missions should be encouraged. Likewise, SEC, ASO, and SEU should plumb the 
potential payoff of IT infusion by refining IT requirements for their missions. 

Finding 4. Continual repackaging of NASA’s IT programs has hampered a sustained focus. 
These changes also make it more difficult to assess in detail the strategic alignment of the 
programs. Looking several years ahead, general OSS IT needs are likely to be reasonably stable 
and should allow for a consistent and predictable application of IT capability. 

Recommendation. To the extent possible, development in core areas of IT should be kept stable 
and sustained in order to allow time to mature adequately and ultimately to achieve mission 
infusion. IT, like any other technology, takes significant time to mature, and disruption of the 
supporting program(s) and/or funding not only interferes with development of the technology 
capability and personnel but also adversely affects the customer/provider. 

Finding 5. In the course of the IT AS, IT providers repeatedly expressed a general desire to align 
their technology programs with strategic goals of OSS, but they also expressed difficulty in 
understanding and following changing needs. NASA’s Technology Inventory and the OSS 
Strategic Technology Steering Group (TSG) database potentially provide capable mechanisms 
for alignment and assessment of technology programs. However, the granularity and quality of 
specific entries in the Technology Inventory and the TSG Database varies greatly and the records 
are not consistently maintained. Unfortunately, the shortcomings of these database tools lead 
some to dismiss their utility for learning of both technology development and strategic needs. 
Recommendation. Managers of technology programs, advanced mission studies, and theme 
technologists must take a more vigorous role in assuring the quality and integrity of the 
databases that presently support alignment and infusion of technology. We recommend that both 
OAT and OSS institute and enforce standards for the collection and categorization of mission 
and technology needs (e.g., as represented by the Technology Inventory and the TSG Database), 
and their timely maintenance. In OSS, we recommend greater ownership of the technology 
requirements by projects and programs. Owners of the two databases, or their equivalents, 
should consider twice-annual review and updating of data as a means of maintaining truly useful 
records. 

Objective 2. Identify products that industry and other government agencies can best supply or 
perform. 

Finding l. Industry support to NASA programs in computer hardware, networking equipment, 
software and services is substantial. However, we find a number of unique, core OSS needs that 
require NASA technology leadership. These include reliable flight software, highly robust 
autonomous systems, space avionics for extreme environments, modeling and simulation of 
complex space science systems, and IT for science discovery and understanding. 
Recommendation. NASA should continue to rely on industry for IT products and services such 
as high-performance computing, networking, and ground communications, where the 
infrastructure and substantial investment resulting from the existence of a viable commercial 
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market will continue to set the pace for technology and product development. In almost all 
cases, NASA should continue to develop lasting capability in-house only where it cannot be 
reliably provided by the commercial sector. 

Finding 2. By and large, OSS missions may not represent a highly lucrative market for industry 
IT development in and of themselves. However, there may be commercial spinoffs from 
successful cutting-edge development. Infusion of NASA-developed IT into the commercial 
sector should be encouraged as capabilities are developed. Such infusion to industry is critical as 
we rely heavily on several key aerospace providers for much of our flight hardware. 
Recommendation. NASA should develop and exercise viable plans for transferring successful 
NASA IT developments to industry, ensuring reliable future suppliers of IT products for NASA 
needs. 

Finding 3. Basic research in IT is largely the province of academia and government (NSF, 
DARPA, NASA). Most development in the private sector is now tightly bound to product 
development, with some notable exceptions (e.g., Java). 

Recommendation. NASA should explore expanded opportunities for collaboration and 
complementary development with NSF and DARPA, or other organizations that have large 
and/or productive IT programs. 

Finding 4. Industry participants in the IT AS expressed surprise that NASA does not typically 
use software frameworks for large, complex development efforts. 

Recommendation. Learning from industry’s experience, NASA should consider approaches 
utilizing software frameworks for improving the development and level of infusion of new 
software developments into flight and ground system infrastructure. 

Objective 3. Recommend a technology infusion strategy to make available the appropriate 
information technology to our missions. 

Finding 1. Clearly, technology infusion is a complex technical and institutional issue, and the 
IT AS showed that NASA is not the only organization to struggle with infusion. Most of the 
successful infusion stories involve close cooperation between those developing IT and 
implementers usually at the same flight center. 

Recommendation. The problem of infusion warrants further detailed, end-to-end study. Any 
such study should solicit the involvement of the major commercial providers for space systems, 
because ultimately they strongly influence the infusion of IT into space missions. The study 
should document past success stories and identify the specifics of a more proactive approach. 
Efforts should be directed toward promoting and sustaining closer collaboration between the IT 
research community and IT implementers at NASA flight centers. 

Finding 2. The existing OSS technology programs for mid-TRL development are not sufficient 
to complete both development and infusion of the full spectrum of IT products. Right projects, 
and even flight programs, typically have a short-term focus. They rationally concentrate scarce 
resources on a small number of key enabling technologies to the neglect of technology that is 
broadly beneficial. New Millennium Program, the only Enterprise-wide program addressing 
mid-TRL technology, funds only developments that require flight validation. The absence of a 
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mid-TRL program addressing IT infusion across all Enterprise Themes may contribute 
substantially to the low infusion of IT into missions. 

Recommendation. Resources need to be committed to mid-TRL development and infusion, 
especially for technology with broad potential payoff to OSS. A balanced portfolio of 
technologies in development should include those whose infusion will enable strategic missions, 
and those that, while less critical, nevertheless greatly enhance future mission capabilities. 

Finding 3. Market incentives play a dominant and critical role in the infusion of IT into 
commercial products. In some instances, successful companies cultivate intermediary infusion 
groups possessing an obsessive customer focus. Conversely, neither providers nor customers in 
the agency are infusion-driven, and few incentives exist to provide impetus to either community 
to effect successful mechanisms. In fact, there are often negative incentives in place; for 
example, a provider bias against development viewed as already mature, or a mission aversion to 
any technology development perceived as adding risk to a flight project. 

Recommendation. Though not a profit-driven enterprise, NASA should explore incentives that 
promote IT infusion in the marketplace for applicability in the Agency, both for providers 
(promoting alignment) and for customers (promoting innovation). 

Finding 4. The IT AS has brought customers and developers together and vastly improved their 
mutual understanding. 

Recommendation. This achievement should be sustained and could lead to dramatically 
improved work selection (OAT) and infusion performance (OSS). 

7.1.2 IT Provider Perspective 

This section identifies the views of the IT providers with respect to each study objective and 
offers recommendations for rectifying identified shortcomings. 

Objective 1. Perform a critical assessment of NASA’s planned information technology R&D and 
its relevance to future OSS missions. 

The study team performed a broad review of the OSS IT needs and the current R&D investment 
from both OAT and, to a limited degree, OSS. The report identifies many of the top-level IT 
requirements of the Themes and provides an in-depth description of the current applicable 
technologies being developed. At a high-level, there is good alignment between the OSS IT user 
requirements and the ongoing IT R&D activities. The study, however, did not review the 
ongoing investment in sufficient detail to make an in-depth assessment of this alignment. For 
convenience, the IT description was classified into the following five areas key to OSS missions: 
autonomy, reliable software, modeling and simulation, improved onboard computational 
resources, and science data analysis/knowledge discovery. However, completing a detailed 
mapping of IT needs to technologies and then prioritizing these technologies according to the 
highest priority needs will require additional analysis. This study team did not have sufficient 
resources to permit detailed mapping and assessment of ongoing tasks. It is important that future 
activities of this nature have appropriate scope and focus. 

During the assessment, it was clear that the level of communication between the two primary 
organizations (OSS and OAT) needed improvement. There seemed to be a fair amount of 
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communication at the technical level, but this communication did not extend to high-level 
organizations. Furthermore, communication depended heavily on existing relationships between 
individuals as opposed to a more structured form of interaction. The level of communication at 
all levels improved significantly over the course of the assessment; this communication should 
continue to improve in the future. 

Finding 1. In general, the alignment between the user needs and the IT investments was 
strongest in the area of Planetary Exploration (i.e., the Mars and Solar System Exploration 
Programs). Various information technologies can be viewed as either highly enhancing or 
enabling for many of the missions being considered by these programs. These missions provide 
compelling challenges that are effective at focusing the research and development activities of 
the fr programs. These technologies are also broadly applicable to the requirements of other 
OSS Themes; however, their needs may not be quite as compelling. For example, due to light- 
speed delays and bandwidth limitations, increased autonomy is essential for many deep space 
missions. Similar technology, however, is also applicable to reducing the development and 
operations costs for missions closer to Earth. Thus, certain autonomy technologies might first be 
infused into a planetary exploration mission and then later adopted for use in an Earth-orbiting 
observatory. 

Recommendation. Additional interaction and communication is required to help ensure that the 
current IT investment is leveraged across all of the OSS Themes and is focused to meet their 
requirements. 

Finding 2. The current OSS IT requirements are not clearly defined in a manner that is 
accessible to the technology development programs. Some of these requirements have been 
identified during the assessment; however, additional work is required to specify them 
adequately. The following recommendations identify two activities to help address this problem 
and improve the communication and interaction between OSS and OAT. 

Recommendation A. Define roles and responsibilities — During the assessment, it became clear 
that the two organizations did not have a shared understanding of organizational roles and 
responsibilities. OSS and the OAT CICT and Engineering for Complex Systems (ECS) programs 
should generate a document that clearly delineates roles and responsibilities. In particular, it is 
important to define these with respect to the infusion of technologies into missions. Another key 
issue is to address the responsibility of the OAT program to address OSS unique low-TRL 
requirements. Currently, much of the OAT program attempts to focus on technologies that are 
cross-Enterprise in nature. 

Recommendation B. Define a regular requirements specification and review process — OSS 
and the OAT CICT and ECS programs should agree upon a process for specifying requirements 
and assessing the relevance of the CICT investment to the OSS mission needs. OSS and OAT 
should perform a joint task-level review of the CICT program with respect to the OSS missions. 
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Objective 2. Identify products that industry and other government agencies can best supply or 
perform. 

While the commercial sector is developing a number of technologies that are critical to future 
NASA missions, NASA also has a number of unique needs that currently are not being 
adequately addressed by the commercial sector. Examples include NASA’s special needs in 
autonomy, highly-reliable software, modeling and simulation for virtual mission design, space- 
borne computing, and knowledge discovery to assist in the scientific analysis of massive data 
sets. DARPA shares some of NASA’s needs in these areas although there are key distinctions 
that will likely require different solutions. 

The total DARPA investment for IT R&D in FY01 was $383M while NSF’s was $470M. The 
DARPA investment tends to span a wider range of technology maturity with a clear focus on 
DOD’s needs, while the NSF funding is focused heavily on basic research that has broad 
applicability. 

Finding I. The majority of the technology development work reviewed during the assessment 
seemed to focus on unique NASA needs. Some of these needs are clearly shared by other 
government agencies; however, in general the commercial sector is not addressing many of these 
needs. 

Recommendation. Low-TRL research funded by NASA should continue to focus on unique 
NASA needs that are not being addressed by others. Due to the overlap between other 
government agencies and NASA in a few key areas, the two organizations should continue to 
identify where joint investment in activities can be leveraged. 

Finding 2. NASA currently does not fully utilize state-of-the-practice information technologies 
available from the commercial sector. Often, these technologies can be particularly useful in 
streamlining operations and reducing costs. Application and infusion of these technologies, 
however, often require broad institutional commitment coupled with investments in 
infrastructure. 

Recommendation. Activities designed to facilitate technology infusion into missions should 
include the broad technology spectrum and not focus solely on NASA-developed technologies. 
Furthermore, NASA should prioritize technology according to suitability and then apply 
resources to accomplish its infusion. 

Objective 3. Recommend a technology infusion strategy to make available the appropriate 
information technology to our missions. 

Technology transfer is a difficult and challenging process within any organization for a variety of 
reasons. One of the key factors is the cultural and organizational differences that separate the 
“researchers” who are interested in developing general concepts that have broad applicability and 
the “mission engineers” who are more interested in focused technologies that satisfy the mission- 
specific requirements. Bridging this divide is particularly challenging within NASA due to the 
long lead-time required to plan and execute a mission, coupled with a culture that is generally 
risk-averse. 






218 


Chapter 7. Recommendations 


w 

w 

V 


KJ 

V 

: ^7 

: 

' KJ 

■- 

1 %J 
' V 


C/ 


The commercial partners that participated in the IT AS study highlighted the fact that effective 
technology transfer requires active management of the process to eliminate the separation that 
exists between these two communities and to develop a shared-onus/peer-level model of 
interaction between them. 1 There are three key components of this active management: 

1) Both technology providers and mission developers need to be given appropriate incentives 
to enable an effective technology infusion process. 

2) The development of technology must be appropriately focused on the strategic enterprise 
needs and not just the scientific objectives of the researcher. 

3) Mission developers must incorporate knowledge of advanced capabilities early in the 
mission formulation process. 

The following findings and recommendations highlight specific issues and ideas relating to the 
active management of the technology-transfer process. 

Finding 1. Frequently, the long-term success of a program critically depends upon the adoption 
and infusion of technology that will enable and enhance future missions. However, principal 
investigators, mission managers, and program managers typically base their decisions upon local 
success criteria that are often sub-optimal when viewed from the Enterprise/Agency perspective. 
This is particularly true for technologies that are enhancing (as opposed to enabling), even 
though the total benefit of such technologies from a science-return perspective might be 
significant. Program formulation and management need to take a higher-level view of the entire 
program, as was done in the formulation of the current Mars program, to help ensure that 
technologies are infused when most appropriate throughout the program. 

Recommendation. OSS should consider creative strategies that provide incentives for programs 
to adopt technologies and reward them when they leave a legacy for future missions. This should 
be viewed as a critical part of every program to ensure maximized science return across the 
entire Enterprise. 

Finding 2. Information technologies often impact multiple aspects of the mission and hence 
must be considered early in the mission formulation and design process. Furthermore, it is a 
common practice for early mission formulation teams to base new mission designs (and success 
criteria) heavily on existing capabilities and technologies from prior mission designs without 
regard to emerging technologies. 2 

Recommendation A. Mission formulation teams should include senior-level individuals who are 
knowledgeable about the potential of information technology to enhance a mission. Including 
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1 One possible approach to this problem is to have the research directly managed by the business units. In contrast, 
larger companies such as IBM have found that an organizational separation is important to ensure that the research 
activities focus on broader strategic goals that can be applied across the organization as opposed to the more focused 
tactical goals of an individual business unit. Thus, IBM actively manages the infusion process with an organizational 
structure that maintains some degree of separation between the business units and the research division. Their 
structure is similar to NASA’s in this regard and has been critical to IBM’s long-term success in the marketplace due 
to their continued development and adoption of advanced technology. This separation is particularly important 
within NASA due to the variations and pressures of the budgetary process. 

2 Information technology is often particularly disadvantaged in the formulation process since mission formulation 
teams typically comprise individuals that are more knowledgeable about traditional NASA technologies such as 
propulsion, power management, thermal regulation, etc. 
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information technologists in the mission formulation process will ensure that the missions are 
designed to maximize utilization of these technologies. 

Recommendation B. Mission and technology roadmaps should be developed by mission 
representatives and technologists through joint exercises to ensure that the Agency investment is 
appropriately focused and leveraged. Mission roadmaps should be developed with an eye toward 
validating important technologies required for future missions, as the Mars and Origins programs 
have done successfully. 

Finding 3. There is inadequate proactive planning for technology validation and insertion into 
missions. In particular, the reporting requirements levied on NASA programs actively 
discourage the identification of milestones that depend upon other programs. This motivates 
programs to be conservative with regard to activities that might creatively seek joint funding 
from multiple sources. However, such cross-program planning and coordination is critical to 
technology infusion success. 

Recommendation. Activities in the technology programs and mission programs should be 
funded to realize shared infusion goals in a planned, coupled, progressive fashion, with a 
collective commitment to proceed as long as maturation success continues to be demonstrated. 

To significantly increase technology infusion success, OSS and OAT should establish such a 
collaborative approach that includes jointly-funded activities. 

Finding 4. There is no well-defined and agreed-upon process within the Agency to assist in 
technology infusion. Furthermore, the roles and responsibilities of the different organizations and 
participants are not well-understood. While there are numerous examples of successful 
technology infusion, often these occurred due to the admirable efforts of a small number of 
individuals as opposed to an organizational structure that helped to facilitate the infusion. 
Recommendation A. The successful infusion of technology requires a commitment from senior 
program managers and project engineers and should be viewed as a critical part of their job 
responsibility. When appropriate, additional personnel can be used to assist them in this role to 
help ensure that there is adequate focus and attention paid to this important task. Technology 
programs should identify technology infusion engineers whose role is to initiate and track the 
early activities in a technology-maturation cycle. Later in the life cycle, technology infusion 
engineers should appear in the project context, and have the same status as project system 
engineers. 

Recommendation B. OSS and OAT should consider jointly sponsoring a focused activity to 
address some of the technology infusion challenges that exist in the Agency. This activity 
should provide very specific recommendations to address this problem more effectively! 

7.1.3 Additional IT Provider Findings and Recommendations 

In addition to the findings and recommendations for the three objectives defined within the ITAS 
charter, the assessment identified a number of other issues that require additional attention. 


Software Infrastructure Support 

Successful transition and demonstration of information technology often depends heavily upon 
the software environment in which it is demonstrated and integrated. The importance of 
software infrastructure has been highlighted by IBM, citing the benefit of common software 
architectures and infrastructures that can be used both in the development of technology and in 
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the eventual flight missions. Such shared framework can facilitate the infusion process and 
allows for the amortization of investment in information technology maturation across multiple 
missions. 

Finding. Software infrastructure and reuse are critical to the cost-effective deployment and 
infusion of advanced information technology. 

Recommendation. OSS should consider how to support the development of common software 
frameworks such as the Mission Data System and the CLARAty rover software architecture. 
Success for such architectures requires equal parts institutional commitment and perceived 
value-added by customer projects and programs. 

Onboard Computational Resource Improvement 

All user participants agreed that it was very important to have future onboard processing power 
that is roughly equivalent to the capabilities currently available in COTS products within the 
commercial sector. Current investment in this area appears limited in FY02 and beyond. 

Finding. One of the key needs within OSS is improved onboard computational resources for 
many of the missions that are currently being considered by OSS. 

Recommendation. OSS and OAT should work together to find a way to support this important 
area of work that has unique NASA applications. 

Science Product Generation 

Enterprise mission formulation teams and technologists frequently give inadequate forethought 
to mission requirements for science products and corresponding technology needs for data 
analysis and knowledge discovery. Understandably, much of their attention is focused on the 
formulation, implementation and operation of the instrument and spacecraft. The end-to-end 
information system is effectively the “central nervous system” for the mission. Yet, often there 
is only minimal information-systems engineering performed, especially with respect to the 
science end products. 

Finding. There is inadequate emphasis on the IT aspects of science product generation and 
knowledge discovery during mission formulation. 

Recommendation. The importance of end-to-end information-systems engineering and system- 
level IT capabilities should be emphasized early and throughout the mission life cycle. IT 
systems engineers and technologists should be included on mission formulation and design teams 
to facilitate thorough end-to-end analysis and preparation for effective science data product 
generation, analysis, and knowledge discovery. 

Reliable Software Development 

Finding. An emerging theme within OSS and across NASA is the need to produce highly 
reliable mission software. Addressing this challenge requires advances both in technology areas 
as well as the utilization of best-practices and well defined processes to help improve the 
reliability of software. IT as discussed within the scope of this report is making relevant 
contributions in the technology development area — for example formal methods for verifying 
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software, and architectures that can stabilize core software-based functionality for missions. 
Also, there are efforts underway to improve software best practices, particularly at the mission 
centers, with Agency endorsement and oversight. These process-improvement efforts toward 
reliable software are, however, outside the scope of this report. 

Recommendation. The software process improvement efforts at the mission centers include, by 
design, provisions for infusing relevant software engineering tools and technologies into 
standardized tool chains and development environments as part of establishing institutional best 
software practices. By way of coordinating technology infusion efforts supportive of reliable 
software, the IT programs should establish explicit points-of-contact with the center software 
process improvement efforts. 


7.2 Comments from Outside NASA 

Representatives from commercial, academia, and other government agencies offered the 
following remarks. 

Finding 1. Collaboration. (NSF) The overlap between the NASA themes and the NSF ITR 
themes affords significant opportunity to collaborate. ( DARPA ) Many of the NASA IT needs 
identified in the June symposium coincide with research being done at DARPA. ( Oracle ) We 
believe there are many opportunities for Oracle-NASA interaction. (IBM) NASA technologies, 
especially in support of scientific collaboration, appear to be a broader use within the 
Government. Customer focus dominates the IBM approach to applied research. A corresponding 
methodology, including institutionalized, replicable process for selection and management of 
projects, based on mission partners and mission focus is applicable to OSS. NASA faces the 
challenge of being customer-focused in a situation where the Federal acquisition process 
modifies the direct, competitive marketplace in which a commercial enterprise operates. 
Recommendation A. (NSF) Plans are currently being considered to collaborate with NASA on 
funding a NSF ITR large proposal on rovers to collect glaciations in Antarctica this fiscal year. 
Collaborations can be developed between the two agencies using established funding 
mechanisms. 

Recommendation B. (DARPA) The best way to explore the possibilities of joint efforts is to talk 
with the program managers, get a detailed understanding of what they are pursuing and not 
pursuing, discuss mutual areas of interest and possibilities, and look for flexibility in the 
programs’ current schedules and funding to accommodate change and/or to participate in our 
conferences and research evaluations. Improved dialogue among researchers, acquisition 
program managers, and users is an effective way to improve the transition of technology. 
Recommendation C. (NSF) A close customer-supplier interaction would be an ongoing process. 
Recommendation D. (IBM) Intra-go vemmental partnering may provide greater payoff for IT. 
Recommendation E. (IBM) IBM and OSS formulate very similar strategic objectives, and it 
appears that mutual exploration of management approaches to successfully executing such 
similar strategies might be useful to each organization. 

Recommendation F. (IBM) The acquisition process can be tailored, especially in the concept 
exploration phase of new missions, to provide a structured opportunity for NASA to try new 
approaches initially in parallel and in competition with established approaches. 


222 


Chapter 7. Recommendations 


V-/ 

U 

V 

V_7 

w 




' 

s-/ 


■ V 

; y__/ 

i 

i ^ 
i ^ 

! 

; ^ 
' ^ 

w 

V-/ 

; \J 

'■ ^ 


Finding 2. Requirements. ( Oracle ) A valuable aspect of the process is mission folks and IT 
providers working together. There has not, however, been a similar emphasis on planning for 
improved communication process among users and providers, a key insight from the Ventura 
conference. (Academia) NASA-wide IT research programs enable focusing of resources to 
develop communities of competency within the NASA IT research organization and within the 
affiliated research communities. Members of these communities are expert in the particular 
technical areas that may contribute to addressing the challenge, and they are also familiar with 
NASA mission challenges that motivate the IT research program. (IBM) If multiple vertically- 
integrated missions are considered, it is apparent that horizontal threads or layers of commonality 
can be perceived. This leads directly to the concept of a shared IT infrastructure spanning many 
missions, where certain commonality and reuse can be exploited at lower layers, and mission- 
specific applications can be built on a common infrastructure. This observation connects most 
directly with the third of the technology maturation paradigms discussed for IBM Research, 
namely pushing innovation into a common infrastructure to increase the value and decrease the 
complexity of mission-specific applications. 

Recommendation A. ( Oracle ) Industry should have an opportunity to learn about NASA 
requirements and use these to influence advanced product development. A good start would be 
participation in the High-Dependability Computing Consortium (HDCC). 

Recommendation B. (Academia) Interaction among NASA personnel and exposure to NASA 
problems will foster this familiarity. It can enable researchers to consider NASA challenges at 
the earliest stages of their work and also incentivize them to employ NASA experience and 
artifacts in validating concepts as they are developed. This kind of approach can result in 
accelerating the process of advancement along the TRL scale. 

Recommendation C. (IBM) NASA may want to look for horizontal threads or layers of 
commonality leading to possible shared IT infrastructure (spanning many missions). 

Finding 3. Products. (IBM) Some of NASA’s IT research is driving commercial interest; e.g., 
requirement for reliable software and fundamental work in distributed supercomputing. ( Oracle ) 
The notion of reusability, especially for in-flight systems, seems to be at best weakly supported. 
The most I heard was that a given site would reuse technology it had developed for previous 
missions, but not that sites would contribute reusable components to NASA, nor that the Agency 
would target investment toward developing and deepening a reusable technology stack. This is as 
much a management challenge as it is a technical challenge; assuming shared risk seems difficult 
for engineers to accept. A major barrier to the development of a reusable platform stack for 
NASA in-flight systems is the exceptionally low computational horsepower and capacity 
available to run such a stack. I believe that many risky design tradeoffs are sanctioned in order 
to work around this extreme set of constraints. (Academia) The most appropriate route of 
technology transition from researcher to NASA may be indirect. If NASA developed a chip 
independently (as is often necessarily the case) then NASA would have to bear the entire cost. 
Recommendation A. (IBM) There are numerous IBM technologies, including microelectronics 
and hardware that have prima facie applicability to OSS mission applications and to a general 
mission infrastructure. OSS is invited to pursue the possibilities of more detailed collaborations 
with IBM. 

Recommendation B. ( Oracle ) A strategy by which a small fraction of mission funding could be 
designated for reusable platform development and enrichment should be considered. Motivating 
and rewarding both producers and consumers of reusable platform technology across missions 
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must start with an explicit top-down mandate to do so. 

Recommendation C. ( Oracle ) Study the implications of low computational capability and 
capacity to determine the feasibility of other approaches. 

Recommendation D. (Academia) NASA should include evaluation of potential investments in 
the underlying technologies to determine if the ability of a vendor to deliver higher levels of 
reliability in designs could be accelerated. 


7.3 Conclusion 

Table 7-1 summarizes the above recommendations in a high-level form that enables comparison 
of the two perspectives and facilitates deriving actionable next steps. In closing, the team 
believes that the overall IT AS activity effectively brought together a broad community including 
diverse technology providers and mission representative consumers. The broad field of 
information technology is critical to many future NASA missions. The cost-effective 
development, maturation, and successful infusion of these technologies into missions will help 
increase science return, reduce cost, and retire risk for future OSS missions. However, achieving 
these goals will require closer coordination and collaboration among the organizational entities 
involved. We believe that this ITAS activity should simply mark the beginning of an ongoing 
improvement process facilitating this collaboration in order to assist the Agency in reaching 
farther in its scientific goals and objectives. 
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Table 7-1. Recommendations Common to Three Assessment Groups 


IT-Provider 

Recommendations 


User 

Recommendations 


Improve alignment and leveraging 
between user needs and IT R&D for 
all Themes (cf. Planetary). 


Improve requirements processes 
jointly between OAT and OSS; 
review CICT with respect to OSS 
needs. 

Develop shared understanding of 
OAT/OSS roles and responsibilities 
re: specification, R&D, infusion 
(particularly for "unique" low-TRL vs. 
"Cross-Enterprise" R&D. 


Improve alignment between IT R&D 
and all OSS divisions, redressing 
perceived imbalance between 
Planetary and others. 


Improve infusion aspects and 
alignment of IT program because 
majority of relevant IT R&D lacks 
defined infusion path, severely 
discounting future value to OSS. 


Keep core areas of IT R&D stable 
and sustained. 


Address limitations of TSG and 
Technology Inventory databases in 
assisting alignment of IT program 
with OSS strategic needs; enforce 
greater ownership of technology 
requirements by Programs/Projects. 


Outside 

Comments 


Continue to focus low-TRL R&D on 
NASA-unique needs; identify 
leverage opportunities. 


Infuse state-of-the-practice 
technologies from non-NASA IT R&D 
(e.g., ops cost reduction); this may 
require broad Agency commitment 
and infrastructure development to 
focus on maturing/infusing mid-TRL 
technologies. 


Encourage NASA technology 
leadership in unique core areas of 
OSS needs in each of the five IT 
categories. Rely on industry for 
HPCC, network and ground 
communications. 


Expand collaboration with other 
government agency large IT 
programs. 


Expand transfer of NASA s/w 
development to industry. 


See Recommendations for Findings 
1, 2. and 3 


Sponsor joint OAT/OSS activity to 
better define infusion approach. 


Include IT-sawy people in 
formulation process and jointly 
develop mission/technology 
roadmaps that validate required 
future technologies. 


Study end-to-end infusion and 
involve space industry. 


Promote and sustain closer 
collaboration between IT R&D and 
flight implementers. 


Recommendation 1C: Ongoing, 
close customer-supplier interaction. 
Recommendation 2B: Promote 
interaction among NASA personnel 
and expose them to NASA issues, to 
consider NASA challenges at early 
stages of work and employ NASA 
experience in validating concepts. 
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IT-Provider 

Recommendations 

User 

Recommendations 

Outside 

Comments 

Couple technology and mission 
program funding to progressively 
realize shared goals, including 
success-based commitment; this 
requires OAT/OSS jointly-funded 
activities. 

Commit resources to mid-TRL 
development, especially strategic 
and highly-enhancing technologies. 

Recommendation 1 F; Acquisition 
process can be tailored to provide 
structured opportunity for NASA to 
try new approaches in parallel and in 
competition with established 
approaches 

Creatively reward successful 
strategic infusion at program level. 
Add responsibility for infusion to 
Senior Program Staff. 

- . 

Explore incentives to infusion on 
both provider and consumer sides. 

Recommendation 2B: Promote 
interaction among NASA personnel 
and expose them to NASA issues. 
Recommendation 3B: Fund reusable 
platform development and 
enrichment. 




Support s/w infrastructure 
development (e.g., MDS/CUVRAty) 
and amortize over multiple missions. 

Develop s/w frameworks for rapid 
insertion of new s/w.* 

Recommendation 2C: Look for 
horizontal threads/layers of 
commonality leading to shared IT 
infrastructure. 

Recommendation 3B: Fund reusable 
platform development and 
enrichment. 

Improve onboard computational 
resources to match 
current COTS capabilities. 

Augment flight processor technology 
to enable realization of IT 
improvements in computation, 
reliable s/w, and autonomy.* 

Recommendation 3C; Study 
implications of low computational 
capability/capacity; determine 
feasibility of other approaches. 

Focus end-to-end information 
system engineering on science 
product/knowledge 
qeneration/anaiysis. 



Create explicit POCs between s/w 
improvement process and 
technologies to increase s/w 
reliability. 


Recommendation 3D: Determine if 
potential investments in technologies 
would accelerate ability of vendor to 
deliver higher reliability. 

Follow-on ITAS activities to facilitate 
OAT/OSS collaboration and process 
improvement to maximize 
effectiveness of IT contributions. 

Sustain the good effort begun by the 
ITAS process.* 

See Finding 1 Recommendations. 


* Included in report as part of Objective 3. 
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Appendix 1. Goals of the Study 

Dear Mr. Peterson and Members of the IT Assessment Teams: 


July 29, 2001 


I was looking forward to participating in person at your conference this week, but regretfully my 
travel to Moscow to discuss Russia’s participation in our Space Science Programs makes this 
impossible. 

I write this to give you my welcome to this workshop and express my appreciation for your 
efforts. 


NASA’s Space Science Enterprise manages some of the most exciting, promising, and difficult 
programs in the country: the unique challenges we face will benefit greatly from the effective 
application of information technology and I am committed to insure that the investment that 
NASA is making in this field is focused on the most relevant issues. 

Your workshop is critical toward this end, and I will rely on your work, analyses, and 
assessments to formulate the Space Science Enterprise posture with regard to information 
technology. Of special significance will be the following: 

1) a critical assessment of planned information technology R&D activities and relevance to 
future OSS missions; 

2) identification of products that industry and other government agencies can best supply or 
perform; and 

3) a recommendation of a technology infusion strategy to make available the appropriate IT 
to our missions. 


To be most useful to NASA, I would like to have your report in the Fall 2001. Thank you very 
much for your support and best wishes for a productive workshop. 

Sincerely, 

Dr. Edward J. Weiler 
Associate Administrator for Space Science 
Code S 
NASA HQ 
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w 

Three workshops were held to gather information and discuss study goals. These are described 
below: 

V 

A2.1 

Ventura Workshop (June 11-13, 2001) 



A2.1.1 

Agenda 


w 

V 


NASA Information Technology Assessment Meeting 
June 11-13,2001 

Sheraton Four Points Hotel, Ventura, CA 
Harbor View Room 





V? 

The purpose of this study is to assess the state of relevant information technology being developed 
or planned in NASA, other government agencies, universities and industry and to identify gaps and 
provide recommendations in order to meet the needs of the OSS mission (beyond 2006) and their 
strategic vision. 

V 

w 

Monday, June 11 



2:00 

Welcome & study objectives 

Harley Thronson, NASA HQ 


2:15 

Introductions, agenda & meeting rules 

John Peterson, JPL 


3:00 

Report outline, assignments & products 

Norm Lamarra, JPL 


3:30 

Break 



3:45 

OSS overview & theme area introductions 

Harley Thronson, NASA HQ 


4:15 

Structure & Evolution of the Universe (SEU) 

Tim VanSant, GSFC 

Ki? 

5:00 

Sun-Earth Connections (SEC) 

Tim VanSant, GSFC 

xy? 

5:45 

Close 


V 

6:00 

Happy Hour 
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NASA Information Technology Assessment Meeting 
June 11-13,2001 

Sheraton Four Points Hotel, Ventura, CA 
Harbor View Room 


Tuesday, June 12 


8:00 Mars Technology Program 

Samad Hayati, JPL 

8:10 

In-Situ Exploration Missions 

Richard Volpe, JPL 

8:30 

Spacecraft Simulation 

Bob Balaram, JPL 

8:50 

Simulating Spacecraft Environments 

Meemong Lee, JPL 

9:10 

Break 


9:30 

Communication & Networks 

Larry Bergman, JPL 

9:50 

Summary 

Samad Hayati, JPL 

10:00 Solar System Exploration Mission Set 

Erik Nilsen, JPL 


IT Requirement Process and Analysis 

Jay Wyatt, JPL 

1 1:30 Astronomical Search for Origins (ASO) 

Rich Capps, JPL 

12:30 Lunch 



1:30 Breakout session instructions 

John Peterson, JPL 

2:00 Breakout sessions meet 


5:00 Integrated perspective of cross-cutting challenges 

Steve Prusha, JPL 

5:00 

Reliable Software 

Eugene Tu, ARC 
Kirk Reinholtz, JPL 

5:10 

Highly Robust Autonomous Systems 

Robert Morris, ARC 
Russell Knight. JPL 

5:20 

Computing, Comm & Distributed Systems 

Roger Lee, JPL 
John Ziebarth, ARC 

5:30 

Mission Design, Develop & Operate 

Meemong Lee, JPL 
Dave Korsmeyer, ARC 


5:40 Close 

6:30 Dinner at 7 1 Palm 


236 


Appendix 2. Workshop Information 


v 

w 








v^' 


X>' 




V 

© 

v_/ 

w 


NASA Information Technology Assessment Meeting 
June 11-13, 2001 

Sheraton Four Points Hotel, Ventura, CA 
Harbor View Room 


Wednesday, June 13 


8:00 ARC IT research overview 
Autonomy 

Highly Reliable Software 
Collaborative Assistant Technology 
High-performance Computing and Networking 
Human Centered Systems 
10:15 Break 
10:30 JPL IT Research 
1 1 :30 GSFC IT Research 
12:30 Lunch 

1:30 Breakout session instructions 
2:00 Breakout sessions meet 

4:00 Integrated perspective of cross-cutting challenges 


Dan Clancy, ARC 
Nicola Muscettola 
Mike Lowry 
Dave Korsmeyer 
John Ziebarth 
Mike Shafto 

Rich Doyle, JPL 
Joe Hennessy, GSCF 

John Peterson, JPL 

Steve Prusha, JPL 


4:00 

Reliable Software 

Eugene Tu, ARC 
Kirk Reinholtz, JPL 

4:10 

Highly Robust Autonomous Systems 

Robert Morris, ARC 
Russell Knight. JPL 

4:20 

Computing, Comm & Distributed Systems 

Roger Lee, JPL 
John Ziebarth, ARC 

4:30 

Mission Design, Develop & Operate 

Meemong Lee, JPL 
Dave Korsmeyer, ARC 


4:40 Review assignments, schedule & next meeting John Peterson/Norm Lamarra, JPL 
5:30 Close 


237 



Appendix 2. Workshop Information 


A2.I.2 Attendance List 


Attendance List - IT Study Group Sheraton Four Points/Ventura - June 11-13 


Name/Title 

Affiliation/Address 

E-Mail 

Tryg Ager 

IBM 

tryg@us.ibm.com 

Dave Atkinson 

Deputy Technical Div. Mgr. 

JPL 

dave.atkinson @ jpl.nasa.gov 

Bob Balaram 

JPL 

j.balaram@jpl.nasa.gov 

Larry Bergman, Section Mgr. 

JPL 

Larry.a.bergman@jpl.nasa.gov 

Barry Boehm, Professor 

use 

Los Angeles, CA 90089-0781 

Boehm@usc.edu 

Guillaume Brat 
Computer Scientist 

Kestrel Technologies 
NASA Ames, M/S 269-2 
Moffett Field, CA 94035 

brat@ ptolemy.arc.nasa.gov 

Rich Capps 

JPL 

richard.w.capps@jpl.nasa.gov 

Daniel Clancy 

Ames 

dclancy® .arc.nasa.gov 

Jim Cutts 

Chief Technologist 

JPL 

M/S 264-426 

james.a.cutts@jpl.nasa.gov 

Tom Cwik 

Technical Group Supvr. 

JPL 

Thomas.A.Cwik@jpl.nasa.gov 

Eric De Jong, Chief Scientist 

JPL 

Eric.M.Dejong @jpl. nasa.gov 

Rich Doyle 
Technical Div. Mgr. 

JPL 

Richard.j.doyle@jpl.nasa.gov 

Maylene Duenas, 

Assoc. Dr. Strategic Dev. 

NASA Ames 

Mduenas @ mai 1 . arc . n asa. gov 

Martin Feather 

JPL 

Martin.s.feather@jpl.nasa.gov 

Mike Freeman 

NASA Ames 

mfreeman@mail.arc.nasa.gov 

Anthony R. Gross 
Assoc. Dr. 

NASA Ames 
M/S 200-6 

agross@mail.arc.nasa.gov 

Samad Hayati, Manager 
MARS Technology Prog. 

JPL 

samad.a.hayati@jpl.nasa.gov 

David Hardison 
Computer Engineer 

Goddard 

David.hardi son @ gsfc .nasa. gov 

Joe Hennessy 
Associate Chief - IS Center 

Goddard 

Jhenness @ pop500.gsfc.nasa.gov 

Jason Hyon 

Deputy Manager - Sec. 389 

JPL 

Jason.hyon@jpl.nasa.gov 

Jeffrey K. Jensen 

Sr. Mgr. Engineering Ops. 

Boeing 

Jeffrey.jensen@west.boeing.com 

Matt Keuneke 

SEC Mission Technologist 

JPL 

Matthew.s.kenneke@jpl.nasa.gov 

Bill Kneisly 
Client Manager 

IBM 

6710 Rockledge Dr. 
Bethesda, MD 20817 

wkneisly @ us . i bm .com 

Russell Knight 

JPL 126/347 

russell.l.knight@jpl.nasa.gov 

David Korsmeyer, 
Technical Area Mgr. 

NASA Ames 

dkorsmeyer@mail.arc.nasa.gov 

Nand Lai 

Goddard 

nlal@pop900.gsfc.nasa.gov 

Norm Lamarra 

JPL 

norman.m.lamarra@jpl.nasa.gov 

Meemong Lee 
Technical Staff Member 

JPL 

meemong.lee@jpl.nasa.gov 

Roger Lee 

JPL 

Roger.A.Lee@jpl.nasa.gov 
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Michael Lowry 

NASA Ames 

mlowry @ mail.arc.nasa.gov 

W 

ASE Area Lead, Sr. Computer 

M/S 269-2 



Scientist 

Moffett Field, CA 94035 



Kathy 1. MacDonald 

DARPA 

kmacdonald @ darpa. m i 1 


Deputy Director, Information 

3701 N. Fairfax Dr. 




Arlington, VA 22203-1714 


V 

Bruce MacNeal, Mgr. 
Technology Integration 

JPL 



David Maluf 

RAICS 

maluf@email.arc.nasa.gov 

v_/ 

Senior Scientist 



o 

Sanda Mandutianu 
Supervisor - Sec. 389 

JPL 

sanda.mandutianu@jpl.nasa.gov 



NASA Ames, M/S 269-2 

morris@ptolemy.arc.nasa.gov 



Moffett Field, CA 94035 



Nicola Muscettola 

NASA Ames, M/S 269-2 

mus@ptolemy.arc.nasa.gov 


Erik Nilsen 

JPL 

Erik.n.nilsen @ jpl.nasa.gov 



NASA Ames M/S 262-1 1 

cnull@mail.arc.nasa.gov 
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John Peterson 

JPL 

John.c.peterson@jpl.nasa.gov 


John Pilat 

Oracle 

john.pilat@oracle.com 


VP Software Engineering 

500 Oracle Parkway, 4 op 12 


— 

Server Technologies 

Redwood Shores, CA 94065 


V' 

Rysszard Pisarski 
Research Scientist 

Ames 

rlp@ptolemy.arc.nasa.gov 


Steve Prusha 

JPL 



Joan Robinson-Berry 

Boeing 



Director, Engineering 

2201 Seal Beach Blvd., MC SD- 



Processes & Tools 

56 

Seal Beach, CA 


^7 

Al Sacks 

JPL 

sacks@jpl.nasa.gov 


William Scherlis 

Carnegie Mellon University 

scherlis@cs.cmu.edu 


Principal Scientist 

School of Computer Science 
5000 Forbes Ave. 

Pittsburgh, PA 15213 



Troy Schmidt 

JPL 

Troy.j.schmidt@jpl.nasa.gov 


Mike Shafto 

NASA Ames 

mshafto @ mail .arc .nasa. gov 


Project Mqr. 

M/S 269-4 


Ben D. Smith 

JPL 

Benjamin.d.smith@jpl.nasa.gov 


Thomas Starbird 

JPL 

Thomas.starbird@jpl.nasa.gov 


Harley Thronson 

NASA Headquarters 

Hthronson @ hq.nasa.gov 


Director of Technology 

Washington, DC 


W 

Dr. Eugene L. Tu 

NASA Ames 

eltu @ mail.arc.nasa.gov 


Chief Tech. Offer. & Acting 

M/S 200-6 



Deputy Dr., Info. Sciences & 
Tech. Directorate 

Moffett Field, CA 94035 


Tim Van Sant 

Goddard 

jvansant@mscmail.gsfc.nasa.gov 
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Guilio Varsi 

HQ 

gvarsi @ mail.hq.nasa.gov 

IP 

Rich Volpe 

JPL 

volpe@helios.jpl.nasa.gov 

John Wright 
Member Technical Staff 

JPL - Section 388 

John.r.wright@jpl.nasa.gov 


E. Jay Wyatt 
Information Systems 
Technology Manager 

JPL 
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Name/Title 

Affiliation/ Address 

E-Mail 

John Ziebarth 

Deputy Division Chief, NAS 

NASA Ames, M/S 258-5 
Moffett Field, CA 94035 

ziebarth@nas.nasa.gov 


A2.1.3 Goals 


Theme Presentations: 

Monday (June 11, 4:15-5:45): SEU, ASO 
Tuesday (June 12, 8:00-12:30): SEC, MEP, ESS 

Each of the 5 OSS Themes will present a (very short) overview of their proposed "Mission Set", 
categorized into Near (01-03), Mid (04-05), and Far terms (06 and beyond) (see Workshop 
Breakouts). The presentation will focus on proposing a set of IT-related "Challenges" for those 
missions, expressed as enabling or enhancing capabilities (without necessarily referring to 
expected solutions) and need dates (e.g., for TRL 3 & 6). Theme technologists will likely 
arrange for their technology experts to present in specific sub-specialties. 

IT Research Presentations: 

Wednesday (June 13 8:00-12:30): ARC, JPL, GSFC 

Each of the participating NASA Technology Providers will present a (very short) overview of 
their research programs. This will include identifying technology products and their estimated 
maturity timeline (e.g., TRL 3 & 6), estimated cost-phasing, and any already-known mappings to 
Mission Challenges. It is desired that the best-fit IT area (Reliable Software,...) is identified for 
each product, and that sufficient detail is provided on the products to enable mapping of Mission 
Challenges (identified during the breakout sessions on Monday) to products during the breakout 
sessions on Tuesday. 

Breakout Sessions Tuesday (June 12 1:30-5:30) 

Each of the OSS Themes will have presented a (very short) overview of their proposed "Mission 
Set" in the Near (01-03), Mid (04-05), and Far terms (06 and beyond) (see Workshop 
Presentations). This will include a proposed set of IT-related "Challenges" for those missions, 
expressed as enabling or enhancing capabilities, without necessarily referring to expected 
solutions. 

The purpose of Tuesday’s breakout session is to attempt to identify commonality of these 
challenges across the Themes. This session will be separated into the the top 4 IT Areas listed 
above, the first two led by ARC technologists (assisted by JPL), while the last two will be led by 
JPL technologists (assisted by ARC). 

It is important that OSS Theme Technologists (and their supporting IT experts) split their time 
appropriately among each of the IT Area breakouts to ensure that their challenges are properly 
represented and understood by the participants in the relevant Areas. It is also an opportunity for 
Theme Technologists to interact with each other to help build a common vocabulary both in 
Mission Themes and IT Challenges. 
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The product from these breakout sessions should look like a (somewhat prioritized) list of IT 
Challenges, each with a timeline showing its applicability to (and need dates for) missions in any 
or all of the 4 Themes. A further product should be a consensus from the Themes on the 
definition of these Challenges to an appropriate level (deeper than a broad generality like "need 
for autonomous operations"). 

Breakout Sessions Wednesday (June 13 1:00-5:00) 

Each of the participating NASA Technology Providers will have presented a (very short) 
overview of their research programs. This will include identifying technology products and their 
estimated maturity timeline, and any already-known mappings to Mission Challenges. 

The purpose of Wednesday’s breakout session (again grouped by IT Area) is to attempt to 
identify commonality of the Technology Products in each Area to the integrated Challenges 
(produced by Tuesday’s breakouts). It is also an opportunity for Technology providers to 
identify related research from others, and for the Theme technologists to understand the goals 
and products enough to bridge the vocabulary gap. Again, the Theme Technologists should split 
their time appropriately among all Areas (even those that may initially appear less relevant) in 
order to ensure that their Challenges are being understood and addressed by the providers. 

The product from these breakout sessions should look like a list of IT research Products, each 
with a timeline showing its applicability to the Mission Challenges. Some prioritization may 
also be possible, for example showing that particular products are "required" for more than one 
Challenge, if agreed by the Theme Technologists. Obvious "gaps" may be noted, either between 
technology readiness and mission need, or between mission need and technology availability. 

It would be ideal if agreement could be reached between Theme Technologists and IT Providers 
on how the former can tell if a Product has effectively addressed the Challenge (e.g., what sort of 
testing or prototype demonstration would be necessary and convincing). A further product 
should be a consensus on the definition of the Products to an appropriate level (deeper than a 
broad generality like "provide autonomous operations"). 

Subsequent Workshop & Breakout Sessions 

During the June workshop, it will likely become clear that significant misunderstandings still 
exist between the expressed Challenges and IT Products. The subsequent weeks will attempt to 
resolve these via iterative conversations between Study Team members and other participants, 
and the draft Study Report will be refined. 

The team will then be ready to reconvene at a second short workshop, attended also by non- 
NASA participants from OGA, Industry, and Academia. This workshop will attempt to refine 
the product by exposing it to the larger context of national IT research, but starting from a point 
which represents at least a shared understanding of Challenges/Products for OSS. Ideally, this 
workshop will identify alignments of both with such national programs, investigate possible 
alliance opportunities, and expose obvious misalignments. Breakout Sessions will be organized 
to facilitate such interaction and capture the results. 
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Output from this workshop will complete the Study Team’s report from this phase of the IT 
Assessment. 
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A2.2 GSFC Workshop (July 31-Aug 1, 2001) 

A2.2.1 Agenda 

Final Agenda 

NASA Information Technology Assessment Meeting 
July 31 & August 1, 2001 
Goddard Space Flight Center 
Bldg 32, East Campus 
Room E103 

The overall purpose of this study is to assess the state of relevant information technology being 
developed or planned in NASA, other government agencies, universities and industry and to identify 
gaps and provide recommendations in order to meet the needs of the OSS mission (beyond 2006) 
and their strategic vision 

A continuation of the June 11-13, 2001 workshop held in Ventura, CA 
Tuesday, July 31 

8:30 Welcome & study objectives 

8:45 Goddard welcome & support 

9:00 Introductions, agenda & updated schedule 

9:30 Report assignments & accomplishments 

10:00 Ed Wei ler’s IT A study perspective 

10:30 Break 

Briefings from external communities 

Each of the named participants below will present a very short overview of their programs; identify relevant products, when the 
products are expected to reach TRL 3 & 6 and any already-known mapping to OSS Mission Challenges. 


10:45 

NSF, Information Technology Research 

Gary Strong, NSF 

11:15 

IBM-Almaden 

Tryg Ager, IBM 

11:45 

Proposed process & schedule for mapping of 
Information Technologies to OSS Mission 
Challenges 

Steve Comford, JPL 

12:15 

Lunch 


1:15 

DARPA, Information Technology Office 

Kathy MacDonald, DARPA 

1:45 

Oracle 

John Pilat, Oracle 

2:15 

University of Southern California 

Barry Boehm, USC 

2:45 

Break 



Harley Thronson, NASA HQ 
Milt Halem, GSFC 
John Peterson, JPL 
Norm Lamarra, JPL 
Harley Thronson, NASA HQ 


Breakouts for mapping of non-NASA IT R&D Programs 

The purpose of Tuesday’s breakout session is to begin to identify the mapping of non-NASA IT 
research programs to the NASA OSS Mission Challenges and identify potential areas for 
external alignment or collaboration. 
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3:00 Discussion of use of DDP for Sections 3 & 5 

( mapping Needs to Products ) Steve Comford JPL, all 

4:00 Review & coordination meeting Dan Clancy, ARC, all 

Meeting with IT area leads 

7:00 Dinner at Chevy’s 

Final Agenda 

NASA Information Technology Assessment Meeting 
July 31 & August 1, 2001 
Goddard Space Flight Center 
Bldg 32, East Campus 
Room El 03 


Wednesday, August 1 

Briefing from the Aerospace Technology Associate Administrator 

8:30 Impact of Information Technology on 

NASA Programs Sam Venneri, NASA HQ 

9:10 Q&A 

9:15 The TSG Database Tim Van Sant, GSFC 

Briefings on mapping of IT to OSS Challenges and write-up status 

Breakout teams present a detailed overview of their study product so far in each of the five 
major IT areas and the other three participating groups (OSS Theme Technologists, NASA IT 
researchers, and non-NASA IT researchers) to jointly validate the Study Product 
accomplishments. 

9:30 Reliable Software Mike Lowry, ARC 

10:30 Break 

10:45 Highly Robust Autonomous Systems Robert Morris, ARC 

1 1 :30 Computing, Comm & Distributed Systems Roger Lee, JPL 

12:15 Lunch 

1:15 Mission Design, Develop & Operate Meemong Lee, JPL 

1:45 Science Data Processing & Analysis Susan Hoban, GSFC 

2:15 Break 

2:30 General Discussion of Assessment process with Harley Thronson, John Peterson 
4:30 Close 
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A2.2.3 Goals 
External Presentations: 

Tuesday (July 31, 10:00-1 1:45a): DARPA, NSF, IBM 
Tuesday (July 31, l:00-3:00p): Oracle, Boeing, CMU, USC 

Each of the Government agencies. Industry and Academic participants has agreed to describing 
their IT research programs within a text section of the Study Report (which is evolving during 
the period between the June and July workshops). Where possible, this text should identify 
when the products are expected to reach TRL 3 & 6, and any already-known mappings to OSS 
Mission Challenges (as discovered during the June Workshop or subsequent telecons). It is 
desired that the best-fit IT area (Reliable Software,...) is identified for each product or capability. 

During the Tuesday presentations, each of the participants named above will present a (very 
short) overview of this text product (describing their IT research programs), perhaps highlighting 
technology-transfer examples of interest to Code S. 

Wednesday (Aug 1, 8:00-10:00) 

This Wednesday morning session is an opportunity for the Breakout Teams to present an 
overview of their product so far in each of the 4 major IT areas. They will thus present their 
view of the mapping of IT research in their IT area to the OSS Challenges. These presentations 
will also present the status of this write-up process. 

Tuesday (July 31 3:30-5:30p) 

During the earlier Tuesday presentations, each of the external participants named above will 
have presented a (very short) overview of their IT research programs, perhaps highlighting 
technology-transfer examples of interest to Code S. 

The purpose of Tuesday’s breakout session is to review this external input in the context of OSS 
Mission Challenges and NASA IT research programs (as presented at the June workshop and 
captured in the draft Study Report). This begins to identify the mapping of the non-NASA IT 
research programs to the NASA OSS Mission Challenges and identifies potential areas for 
external alignment or collaboration. We expect the non-NASA participants and the NASA 
Theme Technologists to split their time at the breakout sessions between the 4 IT areas. 

The product from these breakout sessions should be an update to that already produced by the 
Study Team for the NASA mappings. 

Wednesday (Aug 1, 10:30-12:30) 

The Wednesday morning sessions will have presented an overview of the product from the 
Breakout Team in each of the 4 IT areas, mapping IT products (provided by the IT researchers) 
to OSS Challenges (provided by the Theme technologists). These presentations will also present 
the status of this write-up process. 

The purpose of the last (Wednesday) breakout session is for the three participating groups (OSS 
Theme Technologists, NASA IT researchers, and non-NASA IT researchers) to jointly validate 
the Study Team product so far. This involves agreement from the Theme Technologists that 
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their needs have been properly represented and addressed by the IT providers, and agreement 
from the 2 groups of IT providers (NASA and non-NASA) that their products have been 
adequately represented and mapped to the OSS Challenges. 

Once this product has been "validated", obvious "gaps" may then be noted, either between 
technology readiness and mission need, or between mission need and technology availability. 

Subsequent Study Team Work 

During the June workshop, it became clear that significant misunderstandings exist between the 
expressed Challenges and IT Products. We are attempting to address some of these via iterative 
conversations between Study Team members and other participants, as the evolving draft Study 
Report attempts to adequately represent the Mission Needs and relevant IT research programs. 

During the July workshop, we expect to add external national perspective to these 
considerations, in order to help assess the status of IT research for Code S within NASA. The 
draft report represents a starting-point documenting a shared understanding of Mission 
Challenges/IT Products for OSS. Ideally, subsequent work will identify alignments of both with 
such national programs, investigate possible alliance opportunities, and address obvious internal 
misalignments. In addition NASA hopes to gain useful perspective on the technology-transfer 
process from relevant successful experiences outside NASA (i.e., OGA, Industry, Academia). 

Other issues need to be addressed later. For example, it is desirable to reach agreement between 
Theme Technologists and IT Providers on how the former can tell when a Product will meet/has 
met met the Challenge effectively (e.g., what sort of testing or prototype demonstration would be 
necessary for the latter to convince the former). 

The Study Team’s report from this first IT Assessment will be finalized for presentation to HQ, 
expected sometime in August 2001. 
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A2.3 ARC Workshop (September 6, 2001) 


A2.3.1 Agenda 


Preliminary Agenda 

NASA Information Technology Assessment Meeting 
September 6, 2001 
Ames Research Center 
Bldg 269 
Room 179 


The overall purpose of this study is to assess the state of relevant information technology being 
developed or planned in NASA, other government agencies, universities and industry and to identify 
gaps and provide recommendations in order to meet the needs of the OSS mission (beyond 2006) 
and their strategic vision. 

This workshop is a continuation of the June 11-13 workshop held in Ventura, CA and 
the July 31 and August 1 workshop held at the Goddard Space Flight Center. 


Thursday, September 6 


8:30 

Ames welcome 

Dan Clancy, ARC 

8:45 

Introductions, agenda & meeting goals 

John Peterson, JPL 

9:15 

Report assignments & accomplishments 

Norm Lamarra, JPL 

9:45 

Review mission vs IT challenges mapping 

Tom Hamilton & 

Martin Feather by telecon 

10:15 

Break 


10:30 

Infusion process from the Theme perspective 

Jim Cutts, JPL 

11:00 

Infusion process from the IT R&D perspective 

Dan Clancy, ARC 

11:30 

Working Lunch (infusion process discussion) 

All 


12:00-4:30 Workshop session for agreement on IT needs vs IT products matrix 
The goal of this session is for each IT area to get agreement on their matrix from the Theme 
representatives, specifically that: 

1. I agree you have captured my needs and assigned them to phases properly 

2. I understand the table entry mapping your products to my needs 

3. I agree on the level of interest in that mapping (ex., high, medium or low) 

Steve Comford from JPL will be the facilitator for this session 
Each IT area is allocated a maximum of 45 minutes. 
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4:30 Next steps& schedule 
5:00 Close 


John Peterson/Norm Lamarra, JPL 


A2.3.2 


Attendance List 




IT AS Workshop - Ames, September 6, 2001 
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Name 

Affiliation 

Phone No. 

E-Mail Address 1 

Dave Atkinson 

JPL 

818-393-2769 

David. J. Atkinson @ jpl.nasa.gov 

Guillaume Brat 

Kestrel/ARC 

650-604-1105 

brat@email.arc.nasa.gov 

Rich Capps 

JPL 

818-354-0720 

rcapps@jpl.nasa.gov 

Dan Clancy 

ARC 

650-604-2257 

dclancy@arc.nasa.gov 

Jim Cutts 

JPL 

818-354-4120 

james.a.cutts@jpl.nasa.gov 

Eric DeJonq 

Caltech/JPL 

818-354-0302 

eric.dejong@jpl.nasa.gov 

Mike Freeman 

ARC 

650-604-4705 

mfreeman@mail.arc.nasa.gov 

Anthony Gross 

ARC 

650-604-2727 

agross@mail.arc.nasa.gov 

Tom Hamilton 

JPL 

323-290-0246 

hamiltongroup@mediaone.net 

Peter Hughes 

GSFC 

301-286-3120 

peter.hughes@gsfc.nasa.gov 

Jason Hyon 

JPL 

818-354-0730 


Norm Lamarra 

JPL 

818-393-1561 

norm.lamarra@jpl.nasa.gov 

Meemong Lee 

JPL 

818-354-2228 

meemong.lee@jpl.nasa.gov 

Roger Lee 

JPL 1 

818-354-5082 

roger.a.lee @ jpl. nasa.gov 

Michael Lowry 

ARC 

650-604-3369 

lowry@email.arc.nasa.gov 

Piyush Mehrotra 

ARC 

650-604-5126 

pmehrotra@arc.nasa.gov 

Arthur Murphy 

JPL 

818-354-3480 

arthur.j.murphy@jpl.nasa.gov 

John Peterson 

JPL 

818-354-9855 

john.peterson@jpl.nasa.gov 

Steve Prusha 

JPL 

818-354-5323 

stephen.l.prusha@jpl.nasa.gov 

Chris Schwartz 

GSFC/SEU 

301-286-0172 

chris.schwartz@gsfc.nasa.gov 

Mike Shafto 

ARC 

650-604-6170 

mshafto@mail.arc.nasa.gov 

Tim Van Sant 

GSFC 

301-286-6024 

john.t.vansant.1 @gsfc. nasa.gov 

Ben D. Smith 

JPL 

818-393-5371 

Benjamin.D.Smith@jpl.nasa.gov 

Giulio Varsi 

NASA/JPL 

202-358-0283 

gvarsi@hq.nasa.gov 

Jay Wyatt 

JPL 

818-354-1414 

e.j.wyatt@jpl.nasa.gov 

Jerry Yan 

ARC 

650-604-4381 

jyan@mail.arc.nasa.gov 
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A2.3.3 Goals 

The goal of this session is for each IT area to get agreement on their matrix from the Theme 
representatives, specifically that: 

1. I agree you have captured my needs and assigned them to phases properly 

2. I understand the table entry mapping your products to my needs 

3. I agree on the level of interest in that mapping (ex., high, medium or low) 
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A2.4 JPL Workshop (October 23, 2001) 

A2.4.1 Agenda 

ITAS Final Workshop: Preliminary Agenda 

Jet Propulsion Laboratory 
October 23, 2001 
Bldg 126-112 Conference Room 


9:00: Review workshop objectives and process 

9:30: The first topic for discussion is the context for “assessment” of IT for Code S. Namely, 
how we represent the current status of IT given the novelty of this technology area, 
highlight recent successes, and how NASA’s infusion process compares to other 
agencies. (Input on context is expected from the 3 Center IT leads by October 12 for 
discussion prior to the October 23 rd meeting.) 

10:00: Summarize results (into a few statements setting the stage for findings below) 

10:15: The second topic for discussion is to address Ed Weiler’s three IT assessment objectives 
and did we answer them fully. If not, why not? What can we say we accomplished? 

10:45: Summarize results 

1 1:00: The third topic for discussion relates to our findings and recommendations. Can 
we agree that we need to produce findings and recommendations within the report? If so, what 
are they? Take a cut at producing them within this session. And can we generally agree that 
these are our findings? 

11:45: Summarize results 

12:00: Break for lunch 

1:00: The final topic for discussion is how the above topic results relate to the Theme 

findings and recommendations. We should first hear from the Themes on their “draft product” - 
i.e., objectives and outcome. After we hear from the Themes, we will open it up for discussion. 

1:30: Summarize results 

1:45: Present summarized results to Harley Thronson 

2:30: Next steps and agree to a schedule for completing the report 

3:00: Close 
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Appendix 3. Mapping of Information Technologies to OSS Mission 
Challenges 

A3.1 The TSG Database and the NASA Technology Inventory 

Currently, the primary mechanism for mapping Technologies and Products to Code S missions is 
the Technology Steering Group (TSG) Database. The TSG Database was created in February of 
1999 by Code S for use by NASA, but primarily Code S. It is a relational database composed 
primarily of three files of Code S data. 
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1. Missions: Code S missions approved for development or planning by the theme science 
committees; 

2. Requirements: The technology requirements for those missions developed by JPL and 
GSFC; 

3. Products: The Technology being developed by NASA (currently a complete copy of the 
NASA Technology Inventory) 


The database is in Filemaker Pro 5.0 or greater and is cross platform between MACs and PCs. 
Wayne Schober of JPL maintains the server. The mission entries and requirements for those 
missions are maintained by the four Code S theme technologists. 

The access to the database is NASA-wide and there is a list of the people with password access 
that is currently about 70 people. It has primarily been a tool of the four Code S theme 
technologists and Steve Prusha’s planning organization for Code S. However, NMP, Div 31, 
Team X, Code Q, Mars Planning and others have used it as a planning and data resource. 

The current status is that the Missions, Requirements and Products Files are individually in good 
shape, but the links between the Requirements and the new 2001 Products need to be updated 
with about one third of the linking changed with new or dropped task developments in 2001. We 
are also in process of updating the technology taxonomy since the one used by the NASA 
Inventory is insufficient for practical use. 

The database Products or Tasks underway for IT is only as strong as the NASA Inventory inputs 
made from the Centers. In some cases the ARC rolled up tasks into large chunks that do not 
allow much information on individual efforts. In like fashion, JPL and GSFC missions are loath 
to list Information Technology as a "REQUIREMENT" for them to perform a mission since they 
can usually find a work around with existing technology. However, the information in the 
database is enlightening. 
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A3.2 Mapping Missions to IT Challenges 

DRAFT v2 of Missions-Needs mapping 8/22/01 

Martin.S.Feather@Jpl.Nasa.Gov & 

Tom Hamilton <hamiltongroup@mediaone.net> 

CHANGES SINCE 8/14/01 version: 

MEP - refinement of needs, matrix updated; further updated 8/22/01 
SEU - information for remaining two missions added into matrix 
ASO - refinement of needs, matrix updated 

Overall: mappings shown as matrices with textual labels rather than as lists with 
numeric keys. 

The information shown here is derived from the “Theme Technology Draft Writeups/IT 
Challenges” five subsections (ASO, SEU, MEP, ESS, SEC), links to which are on the page: 
https://eis.jpl.nasa.gov/ceegroup/ITAS/Report/index.html 

In particular, we extracted information from the IT needs matrices/lists at the end of each of 
those subsections, and entered that information into Comford et al’s DPP tool. 

Shown on the pages that follow are: 

• The “Missions Tree” (tree-structured list of missions, following the structure of the 
textual descriptions and matrices of the aforementioned subsections). 

• The “Needs Tree” (tree-structured list of IT needs as listed in the IT needs matrices/lists 
of the subsections); due to major differences between the ways the themes presented their 
IT needs, SEC, ESS and MEP have their own subtrees of needs, while ASO and SEU 
share the four needs Autonomy, High Performance, Computing, Highly Reliable 
Software, and Simulation and Modeling 

• The “big picture” of all the mappings from missions to their needs, shown as one vast 
matrix. 

• The individual matrices mapping each of the five mission themes to their IT needs. 

• Concluding observations and suggestions 
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Missions Tree (all) 

1 :MEP - Mars Exploration Program 

1 . 1 :MER - Mars 2003 Lander 
1.2:MRO - 2005 

1 .3:MSL - Mars Smart Lander 2009 (MSL09) 

1.4: Rend Valid 2007 
1 .5:MSR - Mars Sample Return 201 1 
1.6: Post 2011 

2:SEU - Structure and Evolution of the Universe 
2.1:GLAST 
2.2:Constellation-X 
2.3:OWL 
2.4:ARISE 
2.5:SPECS 
2.6:MAXIM 
2.7: LISA 
2.8:Gen-x 
2.9:ACCESS 

3:ASO - Astronomical Search for Origins 

3.1 :How Did We Get Here? 

3.1.1 :HST - Hubble Space Telescope 

3.1 ,2:SIRTF - Space Infrared Telescope Facility 
3. 1 .3:NGST - Next Generation Space Telescope 
3.1 .4:SOFIA - Stratospheric Observatory for Infrared Astronomy 
3.1 .5:FUSE - Far Ultraviolet Spectroscopic Explorer 
3.2:Are we alone? 

3.2.1:Keck Interferometer 
3.2.2:SIM - Space Interferometry Mission 
3.2.3:TPF - Terrestrial Planet Finder 
3.2.4:STARLIGHT 
4:SEC - Sun-Earth Connection 
4. l:Solar Terrestrial Probes 

4.1.1 :MMS - Magnetospheric Multiscale 
4.1.2:GEC - Geospace Electrodynamic Connections 
4.1 .3:MagCon - Magnetospheric Constellation 

4.2:Uving With a Star Missions 

4.2.1 :SDO - Solar Dynamics Observatory 
4.2.2:Sentinels 

4.3:Strategic Missions 

4.3.1 :SP - Solar Probe 
4.3.2:SPI - Solar Polar Imager 

4.3.3:RAM - Reconnection and Microscale Probe 
4.3.4:ISP - Interstellar Probe 
4.4:GSRI 

5:ESS - Exploration Solar System 

5.1 :Comet Nucleus Sample Return 
5.2:Europa Missions 

5.2.1 :Europa Orbiter 
5.2.2:Europa Lander 

5.3:Neptune Orbiter 
5.4:Mission to Pluto 
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Needs Tree (all) 

(Blue text denotes areas that may NOT be IT-related) 

1 Autonomy 

2:High Performance Computing 
2.1 Pentium in space 
2.2:Other? 

3: Highly Reliable Software 

4:Simulation and Modeling 

4.1:Reliable simulation of zero-g performance, based on 1-g tests 
4.2:Reliable simulation of impossible system level testing 
4.3:Other? 

5:SEC-identified-needs 
5.1:Constellation control 
5.2:Phased array antenna 
5.3:On-board computation 
5.4:Formation control 
5.5Aerodynamic stability and control 
5.6 Automated calibration of constellation magnetometers 
5. 7:Fault tolerant avionics 
5.8:Design manufacture and test tools 
5.9:llltra-low power C+DH subsystem 
5.9.1 :0.5 kg, 1.6Wetc. 

5.9.2:0.25kg, 0.8W etc. 

5.10:Ground-based autonomy 
5.11:X-band transponder 
5.11.1:20kg, 20W, $1.4M 
5.11.2:10kg, 10W, $700K 
5.12:Orbit placement & determination 

5.13:3-D models of solar sail interaction with solar wind/plasma environment 

5.14:Ka-Band Frequency 

5.15:Ka-Band SSPA 

5.16:Pointing systems 

5.17:Optical Communications 

5.18:Ground telescopes 

5.19:Space Laser 

5.20:Avalanche Photodiodes 

5.21 :Space telescopes 

5.22:Communications Testbed 

5.23:Propagation Models 

5.24:Continuous and Burst RF Systems 

5.25: Feature/event Recognition 

(continued on next page) 
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6:ESS-identified-needs 
6.1 : Autonomy & Control 

6.1 .1 :S/W Systems for Low-Cost Ops 
6.1.2:Safe Landing Systems 

6.1 ,3:lntelligent Sensing 
6.1.4:Rendezvous & Docking 
6.1.5:Onboard Planning & Execution 
6.1.6:lnstrument Data Processing 
6.1.7:Monitoring & Diagnosis 
6.2:Guidance, Navigation & Control 
6.2.1 : Efficient Trajectory S/W 
6.2.2:Continuous Low Thrust S/W 
6.2.3:General Auto Nav 
6.2.4:Continuous Low Thrust 
6.2.5:Near Small Body 
6.2.6:Near Planetary Ring 
6.2.7:Rendezvous & Docking 
6.2.8:Aerocapture/Aeroman. 

6.2.9:Safe Landing 
6.2.1 0:ln-situ Vehicles 
7:MEP-identified-needs 

7.1 :Space flight avionics 

7.1 .1 :Shorten time for flight qualification 
7.1 ,2:Enable use of COTS in space 
7.1.3:Minimize cost of flight qualification 

7.2:Flight and Ground Software 

7.2.1 :Ground-Flight migration 
7.2.2:Support goal oriented behavior 
7.2.3:lncorporation of legacy code 

7.3:Ground and Onboard Autonomy 

7.3.1 :Collaborative software development 
7.3.2:Collaborative ops environments 
7.3.3:Effective insertion into flight 

7.4:Simulation and Modeling 

7.4.1 Multiple Mission Domain Modeling 
7.4.2:Lifecycle Capability 
7.4.3:Usability 

7.4.4:Validation 
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SEU - Structure and Evolution of the Universe: missions and their needs 



N 


N 


L 

GLAST 

a 

Constellc 

a 

OWL 

a 

ARISE 

a 

SPECS 

a 

MAXIM 

a 

LISA 

a 

Gen-x 

a 

ACCESS 

3 


Autonon 


HHigh 


Highly []Sii nukition and Modeling 


mm. 




Pentium 

in 

space 


Other? 


Reliable 

simulate 

of 

zero-g 
perform- 
based 


Reliable 
simulate 
of 

impossilj 

system 

level 

testing 


Other? 



1. SEU MISSIONS 

2.1:GLAST 

2.2:Constellation-X 

2.3:OWL 

2.4:ARISE 

2.5:SPECS 

2.6:MAXIM 

2.7:LISA 

2.8:Gen-x 

2.9:ACCESS 


Red = Enabling 

Yellow = Highly Enhancing 

Green = Enhancing 


SEU NEEDS 

1 :Autonomy 

2:High Performance Computing 
2.1 :Pentium in space 
2.2:Other? 

3:Highly Reliable Software 
4:Simulation and Modeling 

4.1:Reliable simulation of zero- 
g performance, based on 1 -g 
tests 

4.2:Reliable simulation of 
impossible system level testing 
4.3:Other? 


Note: SEU and ASO originally related their missions to the needs 1,2,3 & 4. 
Subsequently, ASO refined needs 2 and 4 further into ASO-specific needs, namely 2. 1, 
4.1 and 4.2. 

We introduced the "Other? ” categories 2.2 & 4.3 to retain the record of SEU needs. 

It would be desirable to replace "Other? ” with the SEU specific needs, if different from 
ASO’s, or share them when the same (e.g., if SEU also needed “Pentium in space’’ as 
its High Performance Computing need). 
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ASO - Astronomical Search for Origins: missions and their needs 
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2. ASO MISSIONS 

3.1: How Did We Get Here? 

3. 1.1: HST- Hubble Space 
Telescope 

3.1.2:SIRFT - Space Infrared 
Telescope Facility 
3.1.3:NGST - Next Generation 
Space Telescope 
3.1.4:SOFIA - Stratospheric 
Observatory for Infrared 
Astronomy 

3.1.5:FUSE- Far Ultraviolet 
Spectroscopic Explorer 
3.2:Are we alone? 

3.2.1: Keck Interferometer 
3.2.2:SIM - Space Interferometry 
Mission 

3.2.3:TPF - Terrestrial Planet 
Finder 

3.2.4:STARLIGHT 


Red = Enabling 

Yellow = Highly Enhancing 

Green = Enhancing 


ASO NEEDS 

1 :Autonomy 

2:High Performance Computing 
2.1 :Pentium in space 
2.2:Other? 

3:Highly Reliable Software 
4:Simulation and Modeling 

4.1:Reliable simulation of zero-g 
performance, based on 1-g tests 
4.2: Reliable simulation of 
impossible system level testing 
4.3:Other? 


Note: SEU and ASO originally related their missions to the needs 1,2,3 & 4. 
Subsequently, ASO refined needs 2 and 4 further into ASO-specific needs, namely 2.1, 
4.1 and 4.2. 

We introduced the “Other?” categories 2.2 & 4.3 to retain the record of SEU needs. 
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SEC - Sun-Earth Connection: missions and their needs 
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SEC MISSIONS 

4. 1:Solar Terrestrial Probes 
4.1.1:MMS - Magnetospheric 
Multiscale 

4.1 ,2:GEC - Geospace 
Electrodynamic Connections 
4.1.3:MagCon - Magnetospheric 
Constellation 

4.2:Living With a Star Missions 
4.2.1:SDO - Solar Dynamics 
Observatory 
4.2.2:Sentinels 
4.3:Strategic Missions 
4.3.1 :SP - Solar Probe 
4.3.2:SPI - Solar Polar Imager 
4.3.3:RAM - Reconnection and 
Microscale Probe 
4.3.4: ISP - Interstellar Probe 
4.4:GSRI 


SEC NEEDS 

5.1:Constellation control 
5.2:Phased array antenna 
5.3:On-board computation 
5.4:Formation control 
5.5:Aerodynamic stability and 
control 

5.6:Automated calibration of 
constellation magnetometers 
5.7:Fault tolerant avionics 
5.8:Design manufacture and test 
tools 

5.9:Ultra-low power C+DH 
subsystem 

5.9.1:0.5 kg, 1.6W etc. 
5.9.2:0.25kg, 0.8W etc. 
5.10:Ground-based autonomy 
5.1 1 :X-band transponder 
5.11.1:20kg, 20W, $1.4M 
5.11.2:10kg, 10W, $700K 
5.12:Orbit placement & 
determination 

5.13:3-D models of solar sail 
interaction with solar wind/plasma 
environment 

5.14:Ka-Band Frequency 
5.15:Ka-Band SSPA 
5.16:Pointing systems 
5.17:Optical Communications 
5.18:Ground telescopes 
5.19:Space Laser 
5.20:Avalanche Photodiodes 
5.21:Space telescopes 
5.22:Communications Testbed 
5. 23: Propagation Models 
5.24:Continuous and Burst RF 
Systems 

5.25:Feature/event Recognition 
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ESS - Exploration of the Solar System: missions and their needs 
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ESS MISSIONS 

5.1:Comet Nucleus Sample Return 
5.2:Europa Missions 
5.2.1:Europa Orbiter 
5.2.2:Europa Lander 
5.3:Neptune Orbiter 
5.4: Mission to Pluto 
5.5:Titan Organics Explorer 
5.6:Saturn Ring Orbiter 
5.7:Venus Surface Sample Return 


ESS NEEDS 


:SS-identified-needs 
6.1: Autonomy & Control 

6.1.1:S/W Systems for Low COst 
Ops 

6.1.2:Safe Landing Systems 
6.1 .3:lntelligent Sensing 
6.1.4:Rendezvous & Docking 
6.1.5:Onboard Planning & 
Execution 

6.1.6:lnstrument Data Processing 
6. 1.7: Monitoring & Diagnosis 
6.2:Guidance, Navigation & Control 
6.2.1 Efficient Trajectory S/W 
6.2.2:Continuous Low Thrust S/W 
6.2.3:General Auto Nav 
6.2.4:Continuous Low Thrust 
6.2.5:Near Small Body 
6.2.6:Near Planetary Ring 
6.2.7:Rendezvous & Docking 
6.2.8:Aerocapture/Aeroman. 
6.2.9:Safe Landing 
6.2.10:ln-situ Vehicles 
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MEP - Mars Exploration Program: missions and their needs 




Needs 

I-]MEP-IdentiTied-needs | 

m 


Needs 

[-JSpace flight avionics 

[ -JFlight and Ground 
Software 

[]Grourul and Onboard 
Autonomy 


Wfi 


Needs 

Shorten 
time for 
ffiglit 
quaNfica 

Enable 
use of 
COTS in 
space 

Minimize 
cost of 
flight 
qualrfica 

Ground-1 

migratio 

Support 

goal 

oriented 

behavior 

Incorpor 

of 

legacy 

CoBabor 

software 

developi 

Collabor 

ops 

enrvironn 

Effective 

insertior 

into 

Ifiglit 

Multiple 

ffission 

Domain 

Modeling 

Lifecycle 

Capabilil 

iicjjToTTTSJ 

V/alidafio 

Msns 

Msns 

Totals 

0 

0 

0 



0 

0 

0 

D 


0 


mm 

' m 

MER- 

0 










. 



m ■ 

LjMEf 

mro - 

2005 

0 

. 








m 


Mars 

MSL- 

Mars 

0 

Highly 

Enliancii 

'Highly 

Enliancii 

Highly 

Enliancii 

Highly 

Enliancii 

Highly 

Enliancii 

'Highly 

Enliancii 

^Highly 

Enhancii 

Highly 

Enliancii 

Highly 

Enliancii 

'Highly 

Enliancii 

Highly 

Enliancii 

Highly 

Enliancii 

Hiylily 

Enliancii 

Exploi 

Rend 

0 

Si 

'Highly 

Highly 


i;nnr™ 

mm 


MSR- 

Post 


: 


i W 


t ^7 

: 

• w 


: k? 


• w 

: 


7 ^T=? 

I w 

* 

■ 


MEP MISSIONS 

1.1:MER - Mars 2003 Lander 
1.2:MRO - 2005 

1 .3:MSL - Mars Smart Lander 2007 
(MSL'07) 

1.4:Rend Valid 2007 

1.5:MSR - Mars Sample Return 2011 

1.6:Post 2011 


Red = Enabling 

Yellow = Highly Enhancing 

Green = Enhancing 


MEP NEEDS 

7 : MEP-identified-needs 
7.1 :Space flight avionics 

7.1.1 :Shorten time for flight qualification 
7.1 ,2:Enable use of COTS in space 

7.1 .3:Minimize cost of flight qualification 
7.2:Flight and Ground Software 

7.2.1 :Ground-Flight migration 
7.2.2:Support goal oriented behavior 
7.2.3: Incorporation of legacy code 

7.3:Ground and Onboard Autonomy 

7.3.1:Collaborative software development 
7.3.2:Collaborative ops environments 
7.3.3:Effective insertion into flight 
7.4:Simulation and Modeling 

7.4.1 :Multiple Mission Domain Modeling 
7.4.2:Lifecycle Capability 
7.4.3:Usability 

7.4.4:Validation 
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Observations and Suggestions 

The “ideal” mapping would expand each theme to approximately the same level of detail. This 
would facilitate the task of recognizing when the same needs appear in different theme’s 
missions. It is likely that some further refinement of at least some of the themes’ needs is 
warranted to move closer to this goal. 

Specifically, further refinement will let us distinguish among variants of what are currently 
lumped together as a single need. For example, the needs “Autonomy” and “Highly Reliable 
Software” are both rather high level. A (potentially) useful distinction to make would be between 
“hard real time” needs (e.g., Orbit Insertion; Entry-Descent-Landing) when a correct response is 
needed very rapidly, and less pressing (but no less critical) needs (e.g.. Guidance, Navigation and 
Control during cruise) when time pressures are not as great, and fallback to “safe mode” is 
always an option. Mars theme textual writeups do present information to this finer level of detail, 
but we have not “mined” the information from that text. 

One goal of this is to see when there is, and when there is not, overlap between different 
missions needs, even across different mission theme areas. E.g., a need for feature recognition 
may be held by both a Mars surface rover to assist its movement, and an orbiter to assist its 
filtering of huge volumes of data down to an “interesting” subset. 

Discussions suggest there is likely to be uncertainty in these future missions, to the extent that a 
need might escalate from “Enhancing” all the way to “Enabling” if the mission objectives 
become sufficiently aggressive. An example would be the comparison between (say) a Mars ’09 
rover mission with modest levels of science return expected, vs. a highly ambitious Mars ’09 
rover mission with vastly increased levels of science return expected. Autonomy might be 
“Enhancing” for the former, but absolutely “Enabling” for the latter. 

Our suggestion here is to consider listing each alternative as a separate mission (Mars ’09 
modest; Mars ’09 ambitious), which would allow the different scoring of needs relative to these 
two different mission profiles. Alas, this is more work, but it does serve one of the purposes of 
this whole exercise, which is to show more clearly the contribution that IT could make - if with 
autonomy it is possible to get 5 times the science return of a mission without, then autonomy is 
equivalent to reducing mission cost by a factor of 5. 

The MEP portion of the matrix (n.b., for MEP missions in this document, orbiters are not 
included) dramatically exhibit the escalation of needs from “Enhancing” through “Highly 
Enhancing” to “Enabling”, as the missions become further in the future. 

The SEC portion of the matrix shows little in the way of needs in more than one mission, which 
suggests that either this theme has a set of very different missions - so different that their needs 
don’t overlap, or that the refinement into needs isn’t quite at the right level of abstraction to 
make overlap visible. 

The ESS portion of the matrix shows considerable sharing of needs by multiple missions, and the 
needs list itself is illustrative of what we think is the level of detail the mapping exercise should 
be based on. 
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ASO’s refinement of needs into ASO specific ones now allows other themes to examine them, 
and decide whether they too have the same specific needs, or something in the same category, 
but not identical. E.g., ASO missions have a need for a “Pentium in space”. Do other theme’s 
missions have need of the same level of computing performance, or do they have need of 
significantly more? Or significantly less? 

Table A3-1 depicts a portion of the matrix mapping of the themes to the IT challenges. 


Table A3-1. Sample of Themes Mapped to IT Challenges 
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High Performance 
Computing 
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A3.3 Mapping IT Challenges to IT Areas 


The Theme users constructed a mapping between the IT categories and the OSS Themes, where 
yellow represents enhancing, green represents enabling, and blank represents an unidentified 
mapping. 
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A3.3.1 Reliable Software 

Theme needs for reliable software were mapped as shown in the following matrices. 
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Rationale for Spreadsheet Matrix for Reliable Software 

The rows of the matrix correspond to capabilities in reliable computing (as opposed to specific 
products). These capabilities are: managing complexity (using either architecture or software 
process); synthesis (at the following levels: design, program, and certification); verification and 
validation (for both behavioral properties and autonomous systems); and error recovery (which 
consists only of run-time monitoring). 


We use the mission needs of all four themes (SEC, ESS, ASO, and MEP) as headings for the 
columns of the matrix. In some cases, we merged some needs. We also added columns for needs 
v where software reliability can have a big impact, e.g., cost/schedule, or flight phases such as 

w launch. 


Each entry is a number from 1 to 5 indicating what impact we think a specific reliable computing 
technology can have for a specific need (the higher the number the bigger the impact). Blank 
^ entries can signify that either we don’t think we have capabilities that can help for that specific 

^ need or there is no use for any reliable computing technology for that theme need. 
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We now describe the entries for each theme. Note that all reliable computing techniques can 
have a significant impact on cost and schedule (across mission themes) since it can help reduce 
development time and testing. 

SEC 

The columns for SEC are for launch capabilities (not listed as a theme need), constellation 
control (on-board target selection and observation scheduling), formation control (position 
estimation and control as well as distributed coordination), constellation calibration, ground 
operations (consisting of automated sequence generation, target selection and re-targeting, and 
health management), feature and event recognition, and finally cost and schedule (not listed in 
theme needs). 

We do not think autonomy will have a great impact on launch capabilities. Therefore, we believe 
that launch can better benefit from good software process, behavioral V&V, and run-time 
monitoring. Design-level synthesis as well as architecture may help gain a better handle on the 
software module interactions. 

Constellation control can greatly benefit from V&V techniques, program synthesis, and run-time 
monitoring, because it is likely to involve non-deterministic behaviors and a large amount of 
autonomy software. Runtime monitoring can provide a safety net at run-time. Software 
architecture could help sort out high-level design issues and partition the system to increase the 
efficiency of V&V. 

We think that V&V techniques have the best chances of impacting (positively) formation 
control, constellation calibration, and ground operations. Program synthesis can also help for 
position estimation because of its ability to quickly generate software prototypes. Feature and 
event recognition will also mostly benefit from V&V, but it can also greatly benefit from the 
program synthesis capabilities for data analysis software. 

ESS 

For ESS, we added three flight phases (launch, entry/descent/landing, and orbit insertion). We 
believe that almost all reliable computing techniques can have an impact for these phases, V&V 
for autonomy being the exception (because we do not believe much autonomy is required except 
for precision landing). The complexity of the software for these phases is such that architecture 
and process can have a significant impact, especially if they are coupled with behavioral V&V. 
Program synthesis (for state estimation) can also play an important role, and finally, run-time 
monitoring is always useful as a safety net to catch out-of-range data (see Mars Lander failure). 

Most of the other needs listed (i.e., intelligent sensing, rendezvous docking, on-board planning 
and execution, and monitoring and diagnosis) will mostly benefit from good V&V techniques 
(both behavioral and autonomy) and from error recovery capabilities. Architecture can also play 
a big role in managing complexity of onboard planning systems. Instrument data processing can 
greatly benefit from the work on program synthesis for data analysis. 
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ASO 

For ASO we added only two flight phases (launch and orbit insertion), and we think that those 
phases can mainly benefit from architecture, software process, and mostly behavioral V&V, and 
run-time monitoring. Design-level synthesis can also play an enhancing role. 

We really don’t see what role reliable computing can play in on-orbit construction, maintenance 
and repair. However, health management, robust execution, and distributed decision making can 
all greatly benefit from V&V (especially V&V for autonomy since autonomy is likely to be 
heavily used to fulfill these needs). 

MEP 

We’ve added three flight phases for MEP; and the impact of reliable computing for these phases 
is the same for ESS. It also seems obvious that robust reconfigurable avionics can greatly benefit 
from V&V, architecture (for both studying module interaction and helping V&V), and also from 
program synthesis for avionics. 

Goal-oriented behavior will mostly benefit from behavioral V&V, and to a slightly less extent 
from autonomy V&V since autonomous systems are likely to be used to achieve this capability. 
Similarly, since automated path planning, target tracking, resource management, ground 
operations, and on-board science analysis will rely heavily on autonomous systems, they will 
greatly benefit from autonomy V&V and run-time monitoring. Ground ops and on-board science 
analysis can also greatly benefit from the work on program synthesis for data analysis. This is 
also the case for environment characterization, while obstacle detection and avoidance can 
benefit from program synthesis for state estimation. 

Finally, architecture techniques can have a great impact on resource management because it 
helps decomposing and studying a system into meaningful components. 


A3.3.2 Highly-Robust Autonomous Systems 

Theme needs for autonomous systems were mapped as shown in the following matrices. 
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A3.3.3 Computing, Communications, and Distributed Systems 

In order to facilitate discussion of the products of this section, each of the general product 
categories has been broken down into subcategories of related products. 

Onboard Computing: Hardware 




Rad-hard processors 

• RAD750 (JFL) 

FPGAs 

• Ultra-Low Power Radiation Tolerant Reconfigurable FPGAs (LaRC) 
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• Rad-Hard reconfigurable Field Programmable Gate Array (GSFC) 

• Adaptive Computing (GSFC) 

Advanced Technologies 

• Quantum Computing (JPL) 

• Evolvable Hardware (JPL) 

• Miniaturized semiconductor electronic and optoelectronic devices (ARC). 

Onboard Computing: Software 

Operating Systems 

• Flight Linux (GSFC) 

Frameworks 

• MDS (JPL) 

Formation Flying 

• Agent Based Software for the Autonomous Control of Formation Flying Spacecraft (GSFC) 

• Autonomous Command & Control for Formation Right (Formation Control) (GSFC) 

• Formation Flying Control (JPL) 

• Distributed Optical Sensor-based Control (JPL) 

• Self Organizing Spacecraft (JPL) 

• High-Precision Positioning and Alignment for Spacecraft Formation Flying (GSFC) 

Ground Computing 

Parallel and distributed systems 

• Supercomputing testbed (ARC) 

• Information Power Grid (ARC) 

Supercomputing Simulations, Tools and Libraries 

• MLPlib (Ames) 

• HPCC/ESS Parallel Adaptive Mesh Refinement (JPL) 

• HPCC/ESS Commodity Building Block Testbed (GSFC) 

• Exploratory Computing Environment (ARC) 

• Advanced System Design Tools (ARC) 

Advanced Concepts 

• Gilgamesh (JPL) 
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• High Performance Information Technology Integration (JPL) 
Space Communications 

Higher Frequencies ( Ka-band , optical) 

• Ka-Band Ground Terminal Technology Demonstration (GSFC) 

• Ka-band Spacecraft Amplifier (JPL) 

• Ka Band Experiments (JPL) 

• Optical Ground Systems (JPL) 

Larger Apertures 

• Very Large Array Antenna (JPL) 

Coding/Comp ression 

• Channel Coding and Decoders (JPL) 

• Channel Coding Research (GSFC) 

• Data Compression (JPL) 

• High Performance Data Compression (GSFC) 

Tranceivers 

• Software Reconfigurable Transceiver Technologies (JPL) 

• Low Power Tranceiver (GSFC) 

Mars Telecom 

• Mars Telecom Proximity Payload (JPL) 

Space Networks 

• BP Infrastructure for Distributed Space Systems (GRC) 

• Space Data Direct Delivery to Multiple Clients (GRC) 

• Ad Hoc Networks in Space and Surface Systems (GRC) 

• High-Throughput Distributed Spacecraft Networking (GRC) 

• Cooperative Communications for Remote Exploration (JPL) 

• Protocols for Ad-hoc Networks (JPL) 

• Constellation Infrared Communication (GSFC) 

• Next Generation Space Internet Communications Services (JPL) 

• Operating Missions as Nodes on the Internet (GSFC) 

• Technologies for Space Internet Services (GRC) 
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• Onboard Network Routing (GRC) 

Ground Communications 

Networking 

• Gigabit Networking (ARC) 

• Advanced Multicast (ARC) 

• Hybrid Networking (GRC) 

Quality of Service 

• Adaptive Middleware for End-to-End QoS (ARC) 

• Network Quality of Service (ARC) 

Security 

• ISOWan (JPL) 

Theme needs for computing, communications, and distributed systems were mapped as shown in 
the following matrix. 



ASO 


MEP 

ESS 


Onboard hardware 






Rad-hard processors 


4 

5 


4 

FPGAs 


5 

4 


4 

Bio/Nano/Quantum 

1 

3 

3 


1 

Onboard software 






Operating Systems 

? 

3 

4 

4 

3 

Frameworks 

? 

4 

5 

4 

? 

Formation Flying 

? 

5 

2 

0 

5 

Ground Computing 






Parallel and Dist. Systems 

1 

1 

1 

1 

1 

Supercomputing Tools 

1 

1 

3 

1 

1 

Processor-in-Memory 

0 

1 

3 

1 

1 

Space Communications 






Coding/compression 

3 

5 

3 

5 

3 

Space Networks 

1 

3 

3 

0 

3 

Ground Communications 






Networking 

0 

1 

1 

2 

1 

Quality of Service 

0 

1 

1 

2 

1 

Security 

0 

1 

1 

2 

1 


Note: These numbers (1 for lowest relevance, 5 for highest relevance) were agreed by consensus 
of the 5 Theme users at the ARC workshop on September 6, 2001, but represent only “high- 
level” relative interest in the areas as understood by the Theme users. 

Needs not addressed: 

• IT for design and manufacture of large numbers of microsats. 
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A3.3.4 Virtual Mission Lifecycle 

This section provides a mapping between the VML IT products presented in the Section 4.4 and 
the needs expressed by the theme leads. The mapping in this section was developed in two steps: 

Summarize the IT needs with respect to the lifecycle phases - The IT needs listed in this section 
is a summary of the break-out sessions at the July IT AS workshop in Ventura county California. 
Based on the request by the theme representatives, the discussion was organized with respect to 
four major lifecycle phases; concept design, formulation (detailed design), implementation 
(development combined with integration and test), and operation (launch, operation, and 
analysis). In addition to the lifecycle phases of a mission, the IT needs that apply to effective 
program management of multiple missions were addressed. The IT needs are categorized in two 
levels, lifecycle level and theme group level. 

Map the products that enable the capabilities - For each IT product presented in the Section 4.4, 
its relevance to the IT needs was evaluated for five lifecycle phases with four theme groups per 
lifecycle phase. Each center lead defined a relevance metric and applied it to his/her center’s 
products to represent their applicability to the 20 need entries (5 lifecycle phases * 4 theme 
groups/lifecycle phase). The mapping provides the level of relevance per each need entry and the 
range of relevance over the theme areas (single theme vs. cross-theme) and the lifecycle phases 
(single lifecycle phase vs. multiple-lifecycle phases). 

The mapping shows four types of mapping groups, theme-specific & lifecycle-specific, theme- 
generic & lifecycle specific, theme-specific & lifecycle-generic, and theme-generic & lifecycle- 
generic. However, there is a strong desire by all theme groups as well as many IT developers to 
transform the current discontinuous lifecycle phases into a continuous, coordinated lifecycle via 
modeling and simulation (i.e., virtual lifecycle). 

Program Management (LPO) 

In the past, each flight project carried out the entire lifecycle without any infrastructure support. 
With the cheaper, better, and faster mission lifecycle initiative, each theme area plans the future 
missions so that they collectively achieve the ultimate theme goal with incremental validation. 
The IT needs that address multi-mission lifecycle infrastructure development are summarized 
here. 

• MEP (Gl) 

— Lifecycle-tracking H/W and S/W models 

— Common parameter naming 

— Cross comparison of simulation and experiment 

— Hierarchical parameterization of physics/performance of systems, subsystems, 
component, and parts 

— Collaborative engineering systems and trace-ability of requirements among multiple 
design teams 

• ESS (G2) 

— Knowledge management system for missions 
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• SEC (G3) 

— No input 

• ASO/SEU (G4) 

— No input 

Concept Design Phase (LP1) 

The IT needs of this phase focuses on low-fidelity design trade space composition for rapid 
exploration of design options. 

• MEP 

— Low fidelity device and system modeling and simulation 

• ESS 

— Design trade tools 

— Design for human system teaming 

• SEC 

— Common knowledge models and definitions 

— Train-purpose mission lifecycle knowledge capture 

— Lifecycle-tracking knowledge models (decision trace) 

. ASO/SEU 

— Data vs. science vs. system performance trade space composition 

— Semi-autonomous system design tool 

Formulation Phase (LP2) 

The IT needs of this phase focuses on detailed design analysis, end-to-end design verification 
and validation, and high-fidelity mission system model generation. 

• MEP 

— High fidelity device and system models 

— Performance vs Resource usage analysis 

— Operation risk analysis 

— Site property modeling and simulation 

• ESS 

— Safe landing simulation tools 

— In-situ operation design tools 

— Risk assessment tools and models 

— Mission sequence simulation and assessment 

— S/W design verification and validation 

• SEC 

— Multi system constellation design 

— Mission planning tools for constellations 
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— Operation scenario-based mission analysis 

— Lifecycle- wide risk/cost/performance simulation tools 

— Design for constellation communication 

— Collective operation models 

• ASO/SEU 

— Instrument system modeling and simulation 

— Mission operation model 

— Mission performance model 

— Spacecraft system models and simulation 

Implementation Phase (LP3) 

The IT needs of this phase focuses on concurrent engineering of development and test for 
incremental validation of system implementation. 

• MEP 

— Collaborative SAV development environment (open source?) 

• ESS 

— No input 

• SEC 

— Automated group calibration of instruments and systems 

— Instrument calibration tools 

— Efficient pre-launch testing and verification 

• ASO/SEU 

— Verification and validation of autonomous systems 
Operation Phase (LP4) 

The IT needs of this phase focuses on ensuring spacecraft system health, lowering operation cost, 
and improving science return. 

• MEP 

— Automated ground operation 

• ESS 

— Simulation-based operation training 

— Opportunistic science planning/retargeting 

— Monitoring and diagnosis 

— Supervised operation 

— Low-cost long-term ground operation 

• SEC 

— Control and operations for constellation systems 

— Coordinated data measurements and acquisition 
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- Autonomous ground operation 

- Team operations 

- On-board error recovery 

- Monitoring and Diagnosis 

• ASO/SEU 

- Instrument anomaly detection and mission plan adaptation 

- Target tracking 

- Resource planning tools 

- Ground/On-board observation coordination 

- Semi-autonomous/autonomous operation processes. 


Needs vs. Products 

Theme needs for virtual mission lifecycles were mapped as shown in the following matrix. 



LO 




LI 




L2 




L3 




Cl 
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G 
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G 

G1 

G2 

G3 

G4 

G1 
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In this matrix, the five lifecycle phases are represented as LPO. LP1, LP2, LP3, and LP4. Under 
Each phase, the five themes are represented in four groups, MEP (Gl), ESS (G2), SEC (G3), and 
ASO/SEU (G4). The relevance is ranked in five levels where the levels indicate very low (1), 
low (2), medium (3), high (4), and very high (5). The evaluation scores were provided by the IT 
leads of each center representing the IT developers. 

Need List 

• Lifecycle Phase 

— LO: Program management 

— LI : Concept Design 

— L2 : Formulation Phase 

— L3 : Implementation Phase 

— L4: Operation Phase 

• Theme Groups 

— Gl: Mars Exploration Program 

— G2: Earth & Space Science 

— G3: Sun Earth Connection 

— G4: ASO/SEU 

Product List 

• PI 1 : SPICE Ancillary Information System 

• P12: Sax/Luthor 

• P13: Intelligent Mission Model Agents 

• P14: QUORUM 

• PI 5: Science Organizer 

• P16: CIP 

• P21: ROAM (Rover Operation Analysis Model) 

• P22: COMP (Complex Optics Modeling and Prescription) 

• P23: TFP (Telecom Forcast-Prediction) 

• P24: Livingston 

• P25: Java PathFinder (JPF) 

• P31 : DSENDS (Dynamics Simulator for Entry, Descent and Surface Landing) 

• P32: Ripples-MicroHelm 

• P33: ISHTAR 

• P34: Programmable Virtual Mission (PVM) 

• P41: Avionics System Analysis Testbed 

• P42: Terrain Server & Rover FSW Analysis 

• P43: Simulated Science Scenario 
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• P51: OFM (Operator Function Model) 

• P52: OFAN 

• P53: Brahms 

• P54: APEX 

• P55: CATS( Crew Activity Tracking System) 

• P55: Super Resolution Display 

• P57: ShowTime 2.0 

• P61: WITS (Web Interface for Tele-Science) 

• P62: Next-Generation Remote Agent Planner 

• P63: Spacecraft Emergency Response 

• P64: Instrument Remote Control (IRC) 

• P65: Science Expert Assistant (SEA) 

• P66: Virtual System Design Environment (VSDE) 

• P67: Mission Data Warehousing & Mining. 

A3.3.5 Science Data Processing, Access, Analysis, and Knowledge Discovery 


Theme needs for science data processing, access, analysis, and knowledge discovery were 
mapped as shown in the following matrix. 



ASO 

SEU 

MEP 

ESS 

SEC 

Data & Meta Data Format 






Standards 

3 

5 

3 

3 

5 

Interfaces 

5 

3 

5 

5 

3 

Science Data Processing 






On Board Science 

5 

3 

5 

5 

3 

Adaptive Processing 

5 

1 

3 

3 

3 

Data Management 






Distributed Architecture 

5 

2 

5 

5 

3 

Storage Technology 

5 

2 

5 

5 

09| 

Large Scale Data Repository 

5 

2 

5 

5 


Visualization & Simulation 






Large Scale Model/Simulation 

3 

3 

5 

5 

3 

Interactive Visualization 

3 

3 

5 

5 

— 

Data Mining 





■ ■ 

Knowledge Discovery 

5 

3 

5 

5 

3 

Content-based search tools 

5 

2 

5 

5 

2 

Information Management 






Knowledge Management 

4 

1 

4 

5 

2 

Distributed Collaboration 

2 

2 

2 

3 

2 

Communication with diverse 

2 

2 

2 

2 

2 

audiences 
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Note: These numbers (I for lowest relevance, 5 for highest relevance) were not presented at the 
ARC workshop on Sep 6, 2001. These numbers thus only reflects IT personnel’s view on its 
relevance. 

In order to facilitate discussion of the products of this section, each of the general product 
categories has been broken down into subcategories of related products. 

Data and Meta Data Format 

• Standards 

— Standards for Petabyte-Sized Archives/Prototyping (GSFC) 

— Onboard Summarization and Spacecraft-Initiated Operations Technology (JPL) 

— teXtagger: Automated XML Tagging of Natural Language Text (ARC) 

— Development of a Space Science Data System Federation Interoperability Substrate 
(GSFC) 

• Interfaces 

— IAEP SPICE Core Task (JPL) 

— Java Based Information Exchange Support System (GSFC) 

Science Data Processing 

• Onboard Science 

— Data Compression (JPL) 

— Onboard Science Analysis (ARC) 

— Autonomous Landmark-based Spacecraft Navigation System (JPL) 

— Onboard Pattern Recognition for In Situ Science: Detecting and prioritizing Rover 
Science Opportunities (JPL) 

— Region-of-Interest Data Compression with Prioritized Buffer Management (JPL) 

— Autonomous Feature Identification and Data Compression - WINDS (JPL) 

— Real-Time Data Processing Onboard Remote Sensor Platforms (GSFC) 

— Onboard Instrument Data Processing on a Reconfigurable Processor (GSFC) 

• Adaptive Pro cess ing 

— Low Cost Science Processing with PC Clusters (GSFC) 

— MDS Architecture Based Software Frameworks for EDL Applications (JPL) 

— Adapting Coordination and Cooperation Strategies in Teams (ARC) 

— Onboard Instrument Data Processing on a Reconfigurable Processor (GSFC) 

— Context-Model Based Data Typing and Data Compression Techniques for Space 
Applications (GSFC) 

Data Management 

• Distributed Architecture 

— Advanced Space and Ground Systems; Tracking & Data Acquisition Future Systems 
Applications (GSFC) 

— Object Oriented Data Technology (JPL) 

— Distributed Object-Based Frameworks (GSFC) 
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— Advanced Space and Ground Systems; Tracking & Data Acquisition Future Systems 
Applications (GSFC) 

— A Distributed Environment for Onboard Planning and Scheduling (GSFC) 

• Storage Technology 

— Data Distribution and Archiving Technology (JPL) 

— Mass Storage Scalability Analysis (GSFC) 

• Large Scale Active Data Repository 

— A Distributed Database of On-Line Astronomy Preprints and Documents (GSFC) 

— Digital Sky Virtual Observatory (JPL) 

— Standards for Petabyte-Sized Archives/Prototyping (GSFC) 

Visualization & Simulation 

• Large Scale Model/Simulation 

— Computational Aerosciences Computing Testbeds (ARC) 

— Cosmic Microwave Background Data Analysis Tools (GSFC) 

— Model Based Planetary Analysis (JPL) 

• Interactive Visualization 

— Interactive Space Science Visualization (JPL) 

— WebWinds: A Java-based Environment for the Interactive Display and Analysis of 
Scientific Data (GSFC) 

— WebTheme: Visualization and Analysis of Texual Information from the World Wide 
Web (GSFC) 

— 3-D Characterization and Progressive Transmission of Geological Surfaces on Mars 
(JPL) 

Data Mining 

• Knowledge Discovery 

— Reusable Pattern Recognizers for Solar Imagery (JPL) 

— Onboard Science Analysis and Knowledge Discovery (JPL) 

— Knowledge Discovery Support System (JPL) 

• Content-based search tools/agents 

— Product Model Development using Data Warehousing and Data Mining Tools and 
Methods (ARC) 

— Automated Reasoning Research and Experimentation (JPL) 

— Remote Agent for Interferometry (JPL) 

— Resource Management for Real-Time Adaptive Agents (GSFC) 

— Content-Based Metadata System: A Workbench to Prototype Data Mining Concepts 
(GSFC) 

Information Management 

• Knowledge Management 
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— Web-Based Knowledge Management Services for Vehicle Design (ARC) 

— ScienceOrganizer: Knowledge Management for Distributed Science Teams (ARC) 

— Scientists Expert Assistant (GSFC) 

• Distributed Collaboration 

— ScienceOrganizer: Knowledge Management for Distributed Science Teams (ARC) 

— Model Analysis and Synthesis Infrastructure (GSFC) 

— Development of a Space Science Data System Federation Interoperability Substrate 
(GSFC) 
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Appendix 4. DoD 5000 Model for Science/Technology Transition 


DoD 5000 discusses “Rapid and Effective Transition from Science and Technology to Products.” 
This approach requires the Science and Technology (S&T) community to understand and 
respond to the time-phased requirements of the Users of the technology. It also requires the 
systems acquisition community to plan for initial system capability and incremental introduction 
of new technology and hence, to have an intimate knowledge of the readiness of the technology 
for transition. 

A4.1 What is the New DoD 5000 Model? 

The goal of the new DoD 5000 model is a significant reduction in technology cycle time and 
cost, while increasing the ability to incrementally introduces new technologies to military 
systems. This evolutionary acquisition process provides risk mitigation by allowing phased 
integration of technologies into the product. Open systems architecture or the application of 
common components across multiple systems is also addressed as an enabling practice to 
increase affordability and facilitate evolutionary development. 

DoD 5000.2 further clarifies the responsibilities that relate to transition which are: supporting the 
use of commercial technologies and dual use technology development; advising program 
managers of new developments and providing technical advice throughout the acquisition 
process; and conducting and evaluating technology assessments to determine technology 
maturity for transition. 


DoDD 5000.1 

• Rapid Transition From 
S&T to Products 

• Emphasis on Affordability 

DoDI 5000.2 

• Focus on S&T Solutions in 
Pro -Acquisition 

■ Use Mechanisms with User 
& Acquisition Customer to 
Ensure Transition 

DoD 5000.2-R 

• Establish Technology 
Readiness Levels for 
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DoD 5000.2-R requires the major system acquisition program manager to identify critical 
technologies and conduct technology assessments prior to milestone decision points B and C to 
assess technology maturity. Inherent in this process is the use of a technology readiness level 
(TRL) for each crucial technology. 



Appendix 4. DoD 5000 Model for Science/Technology Transition 


The implementation of the new DoD 5000 model will yield increased connectivity, visibility and 
communication among the S&T community, the acquisition community and the users - all of 
which are important for effective transition and affordability. Technology transition for 
affordability is the process of inserting critical technology into military systems to provide an 
effective weapon and support system - at the “best value” as measured by the warfighter. “Best 
value” refers to increased performance as well as reduced costs of development, production, 
acquisition, and life-cycle operations. 

A4.2 What are the Key Elements to Achieve Technology Transition for Affordability? 

• Identify the Customer - The S&T manager must understand the “real needs” and 
requirements of the customer for the technology. 

• Team with the Customer - The S&T manager has to ensure technical attributes, schedules, 
costs and other warfighter needs can be reasonably met. 

• Consider Affordability Early On - The earlier affordability is considered, the more 
effectively the S&T manager can influence the life cycle costs and the affordability of 
products for insertion into military systems. 

• Plan for Transition - The S&T manager will most successfully transition technology by 
working closely with the customer to plan for accepting and implementing the technology. 

A4.3 What are Some Guidelines for Technology Transition? 

It is important for the S&T community to be aware of system needs and to make ‘choices’ that 
favorably affect the utility and supportability of the final product. While the primary role of 
S&T managers is to develop technology not yet fully recognized or accepted by the acquisition 
community and warfighters, the S&T manager must also consider affordability and transition as 
R&D proceeds. 

One of the best practices to achieve technology transition for affordability is for the customer - 
that is the DoD weapon system program office or systems integrator - to be involved early on in 
the development and planned transition of technology. The S&T manager must obtain 
management support to meet affordability goals; develop and execute a training plan; establish 
and track affordability metrics; and, develop a transition strategy. 

A4.4 What are the Key DoD Initiatives to Improve Technology Transition? 

Army - The Army is placing emphasis on Advanced Technology Development Programs to 
help speed the maturation, assessment, and transition of advanced technologies through 
demonstrations conducted with the user. The tool for this transition process is the Master Plan 
(MP), and executive level document required for the Program Manager (PM) to ensure program 
success. 

Technology Readiness Levels are being implemented as a measure of technology maturity and 
its readiness to transition to the next acquisition phase. Inclusion of TRLs not only in the 
weapon systems programs, but in all aspects of S&T technology development, ensures the Army 
S&T community, PM offices and industry have a common understanding of the exit criteria for 
program transition. 
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Future Combat Systems is the Army’s highest priority Transformation Campaign Plan program. 
The Army and D ARP A seek greater technological innovation and will leverage each other’ s 
investments in advanced technologies. 

Navy - The Navy has invested in 12 Future Naval Capabilities (FNC) that represent the highest 
priority clusters of technology needs of acquisition programs and operating forces. By 
emphasizing on 12 capabilities, the Navy will ensure that the most critical needs are above 
critical mass and ready for transition and ultimately into operational status. 

The Navy’s Chief Technology Officer is the senior advocate for the movement of technology, 
identifying emerging technologies of interest and mediating the transition of technology between 
the provider and the acquisition program. This office matches acquisition program needs with 
technology opportunities; provides independent, system-oriented technology assessments; and 
develops policies to improve utilization of technology. 

Responding to top-level requirements for affordability, the Navy’s Corporate S&T Board 
designated reduction of Total Ownership cost an FNC. The Navy has converged on a strong life 
cycle cost reduction S&T program that is fleet integrated, product focused and project oriented. 

Air Force - The Commander, Air Force Research Laboratory (AFRL) has published an 
affordability letter that requires the use of Integrated Product & Process Development on all 
transition programs, the calculation of retum-on-investment and tools and training to implement 
affordability metrics. 

An Affordability Council has been formed with members from each of the AFRL technology 
directorates. The council identifies and shares best practices, reviews progress of affordability 
programs, develops affordability strategy and implementation plans, and monitors and supports 
the implementation of the S&T Affordability Program strategy. 

An Applied Technology Council has been established to provide a forum to facilitate the timely 
and affordable transition of technology to improve warfighting capabilities. This council 
reviews all TRL 6.3 program candidates, assesses warfighter support and provides a plan and 
funding for Technology Transition. 

DARPA - DARPA programs address affordability as one metric in the set of metrics and exit 
criteria guiding each high risk, high payoff technology program. The relative emphasis of cost in 
each program depends on the desires of the transition partner and the program’s technological 
maturity. Aggressive cost targets are often established in DARPA programs to reduce the life 
cycle cost of military systems to which the technology is being transitioned. One mechanism 
DARPA uses to improve affordability is through the use of conventional commercial-off-the- 
shelf components and processes. 

The challenge of transitioning new technologies into products and services used by the final 
customer - that is, the weapon system acquisition program office or warfighter - is a formidable 
task. The success of the technology transition process hinges on reducing the risk of a new 
technology to the point that it becomes more useful for the customer than an existing capability, 
or provides a leap-ahead capability that is worth the necessary investment. 
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DUSD(S&T) Office of Technology Transition - The DUSD(S&T) Office of Technology 
Transition provides several programs that are facilitating integration of commercial and military 
technologies into DoD weapon systems. These programs are developing dual use technologies, 
leveraging commercial technology for application to DoD products, establishing production 
capacity and promoting technology exchange between DoD and the private sector. 

A4.5 Summary 

Technology transition is the process of inserting critical technology into military systems to 
provide an effective weapon and support system at the best value, as agreed to by the developer, 
acquisition manager, user and maintainer. 

Science and technology transition requires strong partners. From the service laboratories, we 
need a stable, long-term investment. From DARPA we need high risk, high payoff technology 
development. From universities, we need new ideas and basic research and knowledge. And 
from industry, we need innovation and creativity leading to competitive and affordable 
operational products and services. All together this will yield a maximum national security 
payoff. 

A4.6 References 

1. Technology Transition for Affordability - A Guide for S&T Program Managers, April 2001 

2. Transitioning S&T Programs - Defense Systems Acquisition Management Course, June 20, 
2001 
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4. Report to Congressional Committees, Technology Transition from the DARPA, June 2001 
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AI 

AISRP 

ARC 

ASO 

ATLO 

AU 

CICT 

CISE 

CLARAty 

CMM 

CMU 

COTS 

CSMISS 

DARPA 

DoD 

DSN 

ECS 

EDL 

EOS 

EOSDIS 

FY 

GN&C 

GPS 

GRC 

GSFC 

HDCC 

HPCC 

HST 

I/F 

I/O 

IPN-ISD 

ISE 

IT 

ITAS 

ITR 

I V&V 

JPL 

LWS 

MAV 

MCO 

MDS 


Artificial Intelligence 

Applied Information Systems Research Program 
NASA Ames Research Center 
Astronomical Search for Origins/Astrobiology 
Assembly, Test, and Launch Operations 
Astronomical unit 

Computing, Information, and Communication Technology 
Computer Information Science and Engineering 
Coupled Layer Architecture for Robotics Autonomy 
Capability Maturity Model 
Carnegie Mellon Unversity 
Commercial-off-the-shelf 

JPL Center for Space Mission Information and Software Systems 

Defense and Advanced Research Projects Agency 

U. S. Department of Defense 

Deep Space Network 

EOSDIS Core System 

Entry, Descent, and Landing 

Earth Observing System 

EOS Data and Information System 

Fiscal Year 

Guidance, Navigation, and Control 

Global Positioning System 

NASA Goddard Research Center 

NASA Goddard Space Flight Center 

High-Dependability Computing Consortium 

High Performance Computing and Communications 

Hubble Space Telescope 

Interface 

Input/output 

Interplanetary Network and Information Systems Program 

Intelligent Synthesis Environment 

Information Technology 

Information Technology Assessment Study 

NSF Information Technology Research Program 

Independent Verification and Validation 

Jet Propulsion Laboratory 

Living With a Star Program 

Mars Ascent Vehicle 

Mars Climate Orbiter 

Mission Data System 
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MER 

MIPS 

MOU 

MPF 

MPL 

MSL 

MTP 

MTP 

NGI 

NIH 

NMP 

NSF 

OAT 

OGA 

OSS 

R&D 

SAIT 

RF 

SEC 

SEP 

SEU 

SLOC 

SSE 

TPF 

TRL 

UML 

use 

v&v 

VML 

WITS 


Mars Exploration Rover 

Million instructions per second 

Memorandum of Understanding 

Mars Pathfinder 

Mars Polar Lander 

Mars Smart Lander 

Mars Technology Program 

Mars Technology Program 

Next Generation Internet 

U.S. National Institute of Health 

New Millennium Program 

National Science Foundation 

NASA Office of Aerospace Technology 

Other Government Agency 

NASA Office of Space Science 

Research and Development 

Space science Applications of Information Technology 

Radio frequency 

Sun-Earth Connection 

Solar Electric Power 

Structure and Evolution of the Universe 

Lines of source code 

Solar System Exploration 

Terrestrial Planet Finder 

Technology Readiness Level 

Unified Modeling Language 

University of Southern California 

Validation and Verification 

Virtual Mission Lifecycle 

Web Interface for Tele-Science 
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